Re: HMC Mail domain
Doug, Brian, Kees, Thank you for your input. Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Latest copy of Enterprise Tech Journal
The reply of ETJ, when I asked if they had a "Letters to the Editor" section: On 2017-01-26 01:31, Denny Yost wrote: > Since you are the owner of software/hardware/services company in the IT > industry, you can submit article for publication once you have signed an > annual promotion contract with us for at least US$6,000 which gives you the > right to guaranteed publication of up to 6 articles meeting our Writer’s > Guidelines. > > Our rule is that any “vendor person” can submit articles that meet our > Writer’s Guidelines and receive guaranteed publication provided they have > such a promotion contract in place with us. If a vendor wants to submit more > than 6 articles, the next level is a $12,000 contract giving you the ability > to submit up to 12 articles per year. > > Of course, both of the above contract levels also provide you with the > ability to advertise with a full-page, four-color ad that same number of > times in one or both of our globally distributed magazines at no additional > cost. > > We would very much like to publish your articles and promote your products! You've got to be kidding? I have to pay? This would make ETJ nothing more than vanity publisher... I'm an unemployed application programmer, who's rather a bit more clever than most application programmers, but whose knowledge is way below that of real systems-programmers. I happen to still have access to a Canada-based publicly accessible z/OS 1.6 system and a somewhat more up-to-date z/OS 1.10 one at home, but who doesn't realistically expect to ever work again, the demand for nearly 57-year old z/OS PL/I programmers, even with 31+ years of experience, and quite a number of RFE's that turned into actual E's, is not particularly large. (Why not learn Java or whatever is in vogue right now? So that I can apply for jobs that tell me that "you will join a young and dynamic team", the phrase that nowadays replaces the illegal "must not be over 30 (or even 25)"...) My wife and I have been getting by on the, admittedly reasonably generous, unemployment benefits provided by the Belgian state, but your "promotion" contract would gobble up a way too large percentage of our annual budget, for no discernible benefit: the, in general, small tools that I still write, mostly because *I* "need" them to make my life easier, are all covered by the GPL V3, so they are free, both as "in freedom" as well as "in beer"! Distributing them under the GPL also means that, other than a moral obligation to correct bugs, which I do take seriously, I can "happily" fall under a bus tomorrow knowing that: "This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details." I'm not in it for the money, I'm in it because I like to give something back to a community that still shares. (And for me real sharing is the kind of sharing that has nothing to do with the so-called "sharing economy" models of Uber, AirBnB, etc, where the 0.001% share in 99.999% of the benefits!) Regards, Robert -- Robert AH Prins robert.ah.prins(a)gmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
A further question regarding COBOL5 and CEEDUMP
A further question: the CEEDUMP we receive in COBOL 5 lacks a dump of the WORKING STORAGE SECTION. Can this be remedied by changing compile-time or run-time parameters? Please advise. Thank you, Steff Gladstone On Sun, Jan 8, 2017 at 6:51 PM, Steff Gladstone wrote: > Are there any whizzes out there who specialize in reading and deciphering > CEEDUMPs? > I have a question for you. In a COBOL5 CEEDUMP, how do I locate the > *index* of an array (i.e., an array that is defined with "indexed by") in > the dump? > > Thanks in advance, > Steff Gladstone > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Paper Tape
(I admit I could miss the information in the thread) What was the speed of tape reader or card reader? Of course I don't mean the device in motion transported on the wheels, but rather data transfer in bytes per second. ;-) -- 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 authorized 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. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2016 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.955.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Paper Tape
Good question. My experience using these devices coupled with a short wave radio gave us a rate of about 150-300 baud. If you figure 8 bits per baud, you get 2400 bps. However, you asked about bytes so I'm thinking we can simply go back to the original number and say 300 BPS. Other hardware configurations would probably give much different results. -- Donald Grinsell, Systems Programmer Enterprise Technology Services Bureau SITSD/Montana Department of Administration 406.444.2983 (D) "I love deadlines. I love the whooshing sound they make as they fly by." ~ Douglas Adams > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of R.S. > Sent: Thursday, January 26, 2017 8:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Paper Tape > > (I admit I could miss the information in the thread) > > What was the speed of tape reader or card reader? > Of course I don't mean the device in motion transported on the wheels, but > rather data transfer in bytes per second. ;-) > > -- > 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 > authorized 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. > > mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.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.2016 r. kapita zakadowy mBanku > S.A. (w caoci wpacony) wynosi 168.955.696 zotych. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Paper Tape
The IBM 1402 reader punch read cards at 800 cards/minute or 64,000 character/minute (1066.67 characters/second) The IBM 2540 reader punch read cards at 1000 cards/minute (1333.3 characters/second) The IBM 2671 paper tape reader read tape at 500 to 1000 character per second. Michael C. O'Byrne Senior Software Analyst - Enterprise Server Foot Locker Corporate Services 7800 W Brown Deer Rd, Milwaukee, WI 53223 (414) 357-4094 From: "R.S." To: IBM-MAIN@listserv.ua.edu Date: 01/26/2017 09:04 AM Subject:Re: Paper Tape Sent by:IBM Mainframe Discussion List (I admit I could miss the information in the thread) What was the speed of tape reader or card reader? Of course I don't mean the device in motion transported on the wheels, but rather data transfer in bytes per second. ;-) -- 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 authorized 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. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2016 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.955.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Paper Tape
The IBM 1402 card reader read cards at 800 cards per minute or 1066.67 characters per second (14XX series). The IBM 2540 card reader read cards at 1000 cards per minute of 1333.3 characters per second (S360 series). The IBM 2671 paper tape reader read 500 - 1000 characters per second. Michael C. O'Byrne Senior Software Analyst - Enterprise Server Foot Locker Corporate Services 7800 W Brown Deer Rd, Milwaukee, WI 53223 (414) 357-4094 From: "R.S." To: IBM-MAIN@listserv.ua.edu Date: 01/26/2017 09:04 AM Subject:Re: Paper Tape Sent by:IBM Mainframe Discussion List (I admit I could miss the information in the thread) What was the speed of tape reader or card reader? Of course I don't mean the device in motion transported on the wheels, but rather data transfer in bytes per second. ;-) -- 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 authorized 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. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2016 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.955.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL: Re: HMC Mail domain
I agree too Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 623 869 5523 Corporate Tieline - 85523 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Doug Sent: Wednesday, January 25, 2017 6:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL: Re: HMC Mail domain Tom, Based on our experience with outlook in the cloud, yes we need to be able to provide a 'valid email address' for our account in the FROM field. Just my 2cents.. Best regards, Doug . On Jan 25, 2017, at 14:46, Tom Mathias wrote: Brian, There is going to be an update to the manual/helps coming in a future release. Now since your problem was fixed by updating the DNS, do you still think there needs to be a way to customize the "FROM:" line as well? Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A further question regarding COBOL5 and CEEDUMP
It would help to know what your current CEE Parms are set at. Could you provide them? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Steff Gladstone > Sent: Thursday, January 26, 2017 7:40 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: A further question regarding COBOL5 and CEEDUMP > > A further question: the CEEDUMP we receive in COBOL 5 lacks a dump of the > WORKING STORAGE SECTION. Can this be remedied by changing compile-time or > run-time parameters? > > Please advise. > > Thank you, > Steff Gladstone > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A further question regarding COBOL5 and CEEDUMP
What version of z/OS are you running? Here is a good description of the CEEDUMP layout https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ceea100/dumphd.htm Enclave Storage Shows the Language Environment heap storage. For C/C++ and PL/I routines, heap storage is the dynamically allocated storage. For COBOL programs, it is the storage used for WORKING-STORAGE data items. This section also shows the writeable static area (WSA) storage for program objects. Other language-specific storage can appear in this section. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Thursday, January 26, 2017 8:58 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: A further question regarding COBOL5 and CEEDUMP > > It would help to know what your current CEE Parms are set at. > > Could you provide them? > > Lizette > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Steff Gladstone > > Sent: Thursday, January 26, 2017 7:40 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: A further question regarding COBOL5 and CEEDUMP > > > > A further question: the CEEDUMP we receive in COBOL 5 lacks a dump of the > > WORKING STORAGE SECTION. Can this be remedied by changing compile-time or > > run-time parameters? > > > > Please advise. > > > > Thank you, > > Steff Gladstone > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Paper Tape
My first experience was with an IBM 2560 on a 370/125. The IBM 2560 Multi-Function Card Machine (MFCM) provides the System/360 Model 20 with a unique and versatile input/output capability. It combines the facilities of a card reader, card punch, collator, interpreter, and card document printer, all under control of the Model 20 processor. (See Fig. 1.) Two card hoppers, an optical read station that reads both primary and secondary cards, a common punch station, an optional printing station, and five selective radial stackers provide the Model 20 system with a card handling capacity never before possible with one pass of the cards. Using the letters "MFCM" was not well thought out in advance... it was a highly effective card shredder at times :-) Len Rugen Metrics and Automation - umdoitmetr...@missouri.edu -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Michael O'Byrne Sent: Thursday, January 26, 2017 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Paper Tape The IBM 1402 card reader read cards at 800 cards per minute or 1066.67 characters per second (14XX series). The IBM 2540 card reader read cards at 1000 cards per minute of 1333.3 characters per second (S360 series). The IBM 2671 paper tape reader read 500 - 1000 characters per second. Michael C. O'Byrne Senior Software Analyst - Enterprise Server Foot Locker Corporate Services 7800 W Brown Deer Rd, Milwaukee, WI 53223 (414) 357-4094 From: "R.S." To: IBM-MAIN@listserv.ua.edu Date: 01/26/2017 09:04 AM Subject:Re: Paper Tape Sent by:IBM Mainframe Discussion List (I admit I could miss the information in the thread) What was the speed of tape reader or card reader? Of course I don't mean the device in motion transported on the wheels, but rather data transfer in bytes per second. ;-) -- 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 authorized 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. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2016 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.955.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL: Re: HMC Mail domain
In my humble opinion this is not a problem with HMC but network/email folks in the organisation. Any HMC name and domain has to be somehow "authorized" within company network. So, *some* effort has to be done, irrespectively of the name of HMC. If I could choose I would pay much more effort into customisation of HMC email content, to make it more clear and comfortable for users. -- 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 authorized 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. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2016 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.955.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Paper Tape
I was an FE back in the day, and we used...well you all can figure out the first 2 letters we called it, the last 2 were card muncher. Doug Fuerst d...@bkassociates.net -- Original Message -- From: "Rugen, Len" To: IBM-MAIN@listserv.ua.edu Sent: 26-Jan-17 11:51:59 AM Subject: Re: Paper Tape My first experience was with an IBM 2560 on a 370/125. The IBM 2560 Multi-Function Card Machine (MFCM) provides the System/360 Model 20 with a unique and versatile input/output capability. It combines the facilities of a card reader, card punch, collator, interpreter, and card document printer, all under control of the Model 20 processor. (See Fig. 1.) Two card hoppers, an optical read station that reads both primary and secondary cards, a common punch station, an optional printing station, and five selective radial stackers provide the Model 20 system with a card handling capacity never before possible with one pass of the cards. Using the letters "MFCM" was not well thought out in advance... it was a highly effective card shredder at times :-) Len Rugen Metrics and Automation - umdoitmetr...@missouri.edu -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Michael O'Byrne Sent: Thursday, January 26, 2017 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Paper Tape The IBM 1402 card reader read cards at 800 cards per minute or 1066.67 characters per second (14XX series). The IBM 2540 card reader read cards at 1000 cards per minute of 1333.3 characters per second (S360 series). The IBM 2671 paper tape reader read 500 - 1000 characters per second. Michael C. O'Byrne Senior Software Analyst - Enterprise Server Foot Locker Corporate Services 7800 W Brown Deer Rd, Milwaukee, WI 53223 (414) 357-4094 From: "R.S." To: IBM-MAIN@listserv.ua.edu Date: 01/26/2017 09:04 AM Subject: Re: Paper Tape Sent by: IBM Mainframe Discussion List (I admit I could miss the information in the thread) What was the speed of tape reader or card reader? Of course I don't mean the device in motion transported on the wheels, but rather data transfer in bytes per second. ;-) -- 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 authorized 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. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2016 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.955.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blockchain
There are just loads of uses and possibilities for blockchain. I had started looking into coding for Bitcoin to use unused cycles on z/OS to make money. But then migrated over to blockchain as a concept to act as a proof or record history. I was pondering single user record concept that would always stay with you. Single source of identification. Of course then there are stories of people losing bitcoins never to recover them... It might make for a bad lost password concept...but It is really exciting stuff. Rob Schramm On Fri, Jan 20, 2017, 5:23 PM Kirk Wolf wrote: Yeah, that was the early comment where I thought it was going to be silly. Kirk Wolf Dovetailed Technologies http://dovetail.com On Fri, Jan 20, 2017 at 1:13 PM, Charles Mills wrote: > Great! (Except for the "some of it running on 1970's mainframes."). > > Charles > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Kirk Wolf > Sent: Friday, January 20, 2017 10:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Blockchain > > Based on previous interest on Bitcoin, I was suspicious of "Blockchain" as > vendor marketing bandwagon-ism and/or finance industry panic. > > But I recently watched this short Ted talk on "Blockchain", which I > initially thought would be just fluff. Some of the ideas near the end > lead me to think that there might be some there there. > > https://www.ted.com/talks/don_tapscott_how_the_blockchain_ > is_changing_money_and_business > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMF QUESTION
Gentle Readers, I am trying to print TYPE 17 records(using IDCAMS PRT command) to find out what dsns were deleted from 15:00 (3.pm.) up to 17:00 (5.pm. The IDCAM report that is produced doesn't seem to give me what I am looking for. I was wondering if someone can validate my input cards. //SYSINDD * INDD(SMF,OPTIONS(DUMP)) START(1500) END(1700) OUTDD(OUTDD1,TYPE(17:17)) /* //STEP2 EXEC PGM=IDCAMS,TIME=1440 //DD1 DD DSN=&&SM11, //DISP=(OLD,DELETE), //DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=4096) //SYSOUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSINDD * PRINT INFILE(DD1) DUMP /* Thanks in advance -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMC Mail domain
This problem hits close to the heart of IBM-Main. I discovered a while back that a new email address could not successfully be registered from within the company network. This might be for a new person or for someone whose email address had changed. After considerable frustration, I learned that the IBM-Main confirmation email sent to a new registrant has a blank 'From' tag. Not structurally invalid, not unregistered. Empty. I assume that it had always been thus, but we hadn't tried to register a new email address in quite some time. Meanwhile our email nannies had implemented a new 'security' measure to reject any email that did not specify a From id. The sender is not verified AFAIK; there just has to be one. The argument is that this one action filters out a lot of true spam. So the confirmation email from IBM-Main looks like spam and is deleted without notice to the recipient. I take it that this is standard List server software behavior. I cannot imagine a business justification for it, but it requires that any new IBM-Main (or RACF-L) user ask for manual intervention from the List owner to add the user by hand. We are not a giant company, but we have several thousand email users. The idea of asking for an exemption for a literal handful of affected users is daunting, especially because the problem could be solved by a simple software change on the List server. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Thursday, January 26, 2017 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: EXTERNAL: Re: HMC Mail domain In my humble opinion this is not a problem with HMC but network/email folks in the organisation. Any HMC name and domain has to be somehow "authorized" within company network. So, *some* effort has to be done, irrespectively of the name of HMC. If I could choose I would pay much more effort into customisation of HMC email content, to make it more clear and comfortable for users. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF QUESTION
1) What does the output say from the IFASMFDP program? The bottom of the listing will tell you how many records were extracted. 2) Go to CBTTAPE.ORG and download DAF. It can read SMF Data and it is easier to extract details like this IDCAMS probably had no records from the IFASMFDP step Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of esmie moo > Sent: Thursday, January 26, 2017 10:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SMF QUESTION > > Gentle Readers, > > I am trying to print TYPE 17 records(using IDCAMS PRT command) to find out > what dsns were deleted from 15:00 (3.pm.) up to 17:00 (5.pm. The IDCAM report > that is produced doesn't seem to give me what I am looking for. I was > wondering if someone can validate my input cards. > //SYSINDD * >INDD(SMF,OPTIONS(DUMP)) >START(1500) >END(1700) >OUTDD(OUTDD1,TYPE(17:17)) > /* > //STEP2 EXEC PGM=IDCAMS,TIME=1440 > //DD1 DD DSN=&&SM11, > //DISP=(OLD,DELETE), > //DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=4096) > //SYSOUT DD SYSOUT=* > //SYSPRINT DD SYSOUT=* > //SYSINDD * > PRINT INFILE(DD1) DUMP > /* > > Thanks in advance > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blockchain
> Rob Schramm wrote: > I had started looking into coding for Bitcoin to use unused cycles on z/OS to > make money. z/Series machines are not geared towards floating point operations the way commodity GPUs, FPGAs, or purposely built BitCoin miners are. So you surely would spend more money on electricity powering the machine than you'd gain through mining BitCoins, as is already the case for GPUs. Moreover, what type of licensing do you have where you can use unused cycles? We have MLC licensing, and as a result we get to use these unused cycles when we need more processing power than we have defined. If we were to use "unused cycles" for other purposes beforehand, it would kick up our 4HRA, and we'd cap much sooner, right when we actually need those cycles to service the business that pays our bills. Regardless, it's fun to know that people out there are looking in to what we can do with blockchain on our machines. Trying new stuff out just for the heck of it will always be a good thing in my book. -- Jan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF QUESTION
There wee 80,958 records printed.I just want to ensure that the parms for the start and stop time is of the proper syntax.. On Thu, 1/26/17, Lizette Koehler wrote: Subject: Re: SMF QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, January 26, 2017, 12:26 PM 1) What does the output say from the IFASMFDP program? The bottom of the listing will tell you how many records were extracted. 2) Go to CBTTAPE.ORG and download DAF. It can read SMF Data and it is easier to extract details like this IDCAMS probably had no records from the IFASMFDP step Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of esmie moo > Sent: Thursday, January 26, 2017 10:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SMF QUESTION > > Gentle Readers, > > I am trying to print TYPE 17 records(using IDCAMS PRT command) to find out > what dsns were deleted from 15:00 (3.pm.) up to 17:00 (5.pm. The IDCAM report > that is produced doesn't seem to give me what I am looking for. I was > wondering if someone can validate my input cards. > //SYSIN DD * > INDD(SMF,OPTIONS(DUMP)) > START(1500) > END(1700) > OUTDD(OUTDD1,TYPE(17:17)) > /* > //STEP2 EXEC PGM=IDCAMS,TIME=1440 > //DD1 DD DSN=&&SM11, > // DISP=(OLD,DELETE), > // DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=4096) > //SYSOUT DD SYSOUT=* > //SYSPRINT DD SYSOUT=* > //SYSIN DD * > PRINT INFILE(DD1) DUMP > /* > > Thanks in advance > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF QUESTION
Esmie moo, The SMF17 record is simple and straight forward as it does not have variable sections or triplets. There are 2 time fields in the SMF layout SMF17TME - Time since midnight, in hundredths of a second, when the record was moved into the SMF buffer. SMF17RST - Time since midnight, in hundredths of a second, that the reader recognized the JOB card (for this job). I assumed that you wanted to extract the data from SMF17RST field. So here is a DFSORT job which will format your entire SMF17 data while extracting the information that ran between 15:00:00(3 pm) and 17:00:00(5 pm). Look at the OUTFIL INCLUDE commands for the inclusion ranges. //STEP2EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD DISP=(OLD,DELETE),DSN=&&SM11, //SORTOUT DD SYSOUT=* //SYSINDD * OPTION COPY,VLSHRT INCLUDE COND=(6,1,BI,EQ,17) $ TYPE 17 INREC BUILD=(1,4, 07,4,TM1,EDIT=(TT:TT:TT), $ SMF17TME X, $ SPACE 11,4,DT1,EDIT=(-TT-TT), $ SMF17DTE X, $ SPACE 15,4, $ SMF17SID X, $ SPACE 19,8, $ SMF17JBN X, $ SPACE 27,4,TM1,EDIT=(TT:TT:TT), $ SMF17RST X, $ SPACE 31,4,DT1,EDIT=(-TT-TT), $ SMF17RSD X, $ SPACE 35,8, $ SMF17UID X, $ SPACE 43,2, $ RESERVED X, $ SPACE 45,44, $ SMF17DSN X, $ SPACE 89,3, $ RESERVED X, $ SPACE 92,1,BI,EDIT=(TTT), $ SMF17NVL X, $ SPACE 93,2, $ RESERVED X, $ SPACE 95,6) $ SMF17FVL OUTFIL VTOF,BUILD=(5,128), INCLUDE=(39,8,CH,GE,C'15:00:00',AND, 39,8,CH,LE,C'17:00:00') //* Further if you have any questions please let me know Thanks, Kolusu IBM Mainframe Discussion List wrote on 01/26/2017 10:21:14 AM: > From: esmie moo <012780d99c7b-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 01/26/2017 10:21 AM > Subject: SMF QUESTION > Sent by: IBM Mainframe Discussion List > > Gentle Readers, > > I am trying to print TYPE 17 records(using IDCAMS PRT command) to > find out what dsns were deleted from 15:00 (3.pm.) up to 17:00 > (5.pm. The IDCAM report that is produced doesn't seem to give me > what I am looking for. I was wondering if someone can validate my > input cards. > //SYSINDD * >INDD(SMF,OPTIONS(DUMP)) >START(1500) >END(1700) >OUTDD(OUTDD1,TYPE(17:17)) > /* > //STEP2 EXEC PGM=IDCAMS,TIME=1440 > //DD1 DD DSN=&&SM11, > //DISP=(OLD,DELETE), > //DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=4096) > //SYSOUT DD SYSOUT=* > //SYSPRINT DD SYSOUT=* > //SYSINDD * > PRINT INFILE(DD1) DUMP > /* > > Thanks in advance > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blockchain
rob.schr...@gmail.com (Rob Schramm) writes: > There are just loads of uses and possibilities for blockchain. I had > started looking into coding for Bitcoin to use unused cycles on z/OS to > make money. But then migrated over to blockchain as a concept to act as a > proof or record history. I was pondering single user record concept that > would always stay with you. Single source of identification. Of course > then there are stories of people losing bitcoins never to recover them... > It might make for a bad lost password concept...but It is really exciting > stuff. Ricardian Contracts In the Media! http://financialcryptography.com/mt/archives/001596.html Ricardian Contract https://en.wikipedia.org/wiki/Ricardian_Contract Where is the Contract? - a short history of the contract in Financial Cryptography systems http://financialcryptography.com/mt/archives/001562.html Yanis Varoufakis proposes Greek tax receipts in Ricardian Contracts on a blockchain http://financialcryptography.com/mt/archives/001555.html Gendal on blockchains -- what's the fuss? Could the blockchain change accounting? http://financialcryptography.com/mt/archives/001540.html even going back to overlap with some standards & patents that I did When the SLippery SLope beckons http://financialcryptography.com/mt/archives/000998.html (Imagine here comments about Ricardian contracts, x.509 failings, x9.59 designs, transaction economics, and a whole host of lessons that simply can't be learnt at any price.) ... snip ... Sarbanes-Oxley is what you get when you don't do FC http://financialcryptography.com/mt/archives/000797.html Reading this posted old reference by Lynn, I was struck by this gem: http://www.garlic.com/~lynn/aepay3.htm#riskm ... snip ... -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Latest copy of Enterprise Tech Journal
>>> On 1/26/2017 at 06:51 AM, Robert Prins wrote: > The reply of ETJ, when I asked if they had a "Letters to the Editor" section: > > On 2017-01-26 01:31, Denny Yost wrote: > > Since you are the owner of software/hardware/services company in the IT > > industry, you can submit article for publication once you have signed an > > annual promotion contract with us for at least US$6,000 which gives you > the > > right to guaranteed publication of up to 6 articles meeting our Writer*s > > Guidelines. -snip- > You've got to be kidding? I have to pay? This would make ETJ nothing more > than > vanity publisher... Yes, and no. The vanity publisher aspect only comes into play when people are writing about something other than what their company sells. I ran into this same problem when I changed jobs and started working for Novell, and now SUSE. Previously I was able to write for ETJ (then zJournal) and get paid for it. When I became the employee of a "vendor" that stopped, and my employer would have to pay for having any articles I wrote published. Even though I don't do marketing of any kind, and am vendor neutral as possible. Now, their rationale isn't completely bogus. They have a lot of companies out there that basically want to publish product promotional articles without them being labeled as such. If someone like you and I were to get published, with or without being paid, those other companies jump all over Bob Thomas about it. This sort of thing is also why IBM stopped paying for non-employee non-customer speakers to present at their conferences. Also an overly simple-minded solution. So, I haven't written for ETJ for years now. (The last article I actually wrote was published under the name of another well-known contributor, not mine.) They were always having problems attracting writers for Linux articles, and I've noticed they haven't had a "pure" Linux article published for quite a while, which is a shame. I didn't mind the loss of income so much, since I was using the funds to donate to a local dog rescue. But the blindly binary decision making ticked me off, particularly since they were already familiar with my work and regularly requested more of it before I changed jobs. Oh well. Their business, their gun, their foot. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF QUESTION
So the report on the far right hand side at the bottom says 80+ records. Starting in Col 1 DATE(ddd,ddd) START(hhmm) END(hhmm) This report show 522 records for SMF 88 Records SUMMARY ACTIVITY REPORT START DATE-TIME 01/26/2017-04:46:23 END DATE-TIME 01/26/2017-12:00:02 RECORD RECORDS PERCENT AVG. RECORD MIN. RECORD MAX. RECORD RECORDS TYPE READOF TOTAL LENGTHLENGTH LENGTH WRITTEN 88 522 .07 % 275.33 161 308 522 Here I have no records SUMMARY ACTIVITY REPORT START DATE-TIME 01/26/2017-04:46:23 END DATE-TIME 01/26/2017-12:00:02 RECORD RECORDS PERCENT AVG. RECORD MIN. RECORD MAX. RECORD RECORDS TYPE READOF TOTAL LENGTHLENGTH LENGTH WRITTEN 88 902 .08 % 277.36 161 308 0 Lizette -Original Message- >From: esmie moo <012780d99c7b-dmarc-requ...@listserv.ua.edu> >Sent: Jan 26, 2017 10:53 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMF QUESTION > >There wee 80,958 records printed.I just want to ensure that the parms for >the start and stop time is of the proper syntax.. > > >On Thu, 1/26/17, Lizette Koehler wrote: > > Subject: Re: SMF QUESTION > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Thursday, January 26, 2017, 12:26 PM > > 1) What does the > output say from the IFASMFDP program? > > The bottom of the listing will tell you how > many records were extracted. > 2) Go to > CBTTAPE.ORG and download DAF. It can read SMF Data and it > is easier to extract details like this > > > > IDCAMS probably had no > records from the IFASMFDP step > > Lizette > > > > > -Original Message- > > From: IBM > Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of esmie moo > > Sent: Thursday, January 26, 2017 10:21 > AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: SMF QUESTION > > > > > Gentle Readers, > > > > > I am trying to print TYPE 17 > records(using IDCAMS PRT command) to find out > > what dsns were deleted from 15:00 (3.pm.) > up to 17:00 (5.pm. The IDCAM report > > > that is produced doesn't seem to give me what I am > looking for. I was > > wondering if > someone can validate my input cards. > > > //SYSIN DD * > > > INDD(SMF,OPTIONS(DUMP)) > > > START(1500) > > END(1700) > > OUTDD(OUTDD1,TYPE(17:17)) > > /* > > > //STEP2 EXEC PGM=IDCAMS,TIME=1440 > > //DD1 DD DSN=&&SM11, > > // DISP=(OLD,DELETE), > > // > DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=4096) > > //SYSOUT DD SYSOUT=* > > //SYSPRINT DD SYSOUT=* > > //SYSIN DD * > > PRINT INFILE(DD1) DUMP > > /* > > > > Thanks in advance > > > > -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF QUESTION
By not specifying a date, you extracted records from the 2 hour window for every day present in the SMF data. While probably not a problem, the ":17" is superfluous for a single record type. As suggested, DAF is the tool of choice for this since it will allow you to eliminate the records for temporary datasets and format the output into something easier to read. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of esmie moo > Sent: Thursday, January 26, 2017 9:54 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF QUESTION > > There wee 80,958 records printed.I just want to ensure that the parms for > the start and > stop time is of the proper syntax.. > > > On Thu, 1/26/17, Lizette Koehler wrote: > > Subject: Re: SMF QUESTION > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Thursday, January 26, 2017, 12:26 PM > >1) What does the > output say from the IFASMFDP program? > > The bottom of the listing will tell you how > many records were extracted. >2) Go to > CBTTAPE.ORG and download DAF. It can read SMF Data and it > is easier to extract details like this > > > > IDCAMS probably had no > records from the IFASMFDP step > > Lizette > > > > > -Original Message- > > From: IBM > Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of esmie moo > > Sent: Thursday, January 26, 2017 10:21 > AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: SMF QUESTION > > > > > Gentle Readers, > > > > > I am trying to print TYPE 17 > records(using IDCAMS PRT command) to find out > > what dsns were deleted from 15:00 (3.pm.) > up to 17:00 (5.pm. The IDCAM report > > > that is produced doesn't seem to give me what I am > looking for. I was > > wondering if > someone can validate my input cards. > > > //SYSINDD * > > > INDD(SMF,OPTIONS(DUMP)) > > > START(1500) > >END(1700) > >OUTDD(OUTDD1,TYPE(17:17)) > > /* > > > //STEP2 EXEC PGM=IDCAMS,TIME=1440 > > //DD1 DD DSN=&&SM11, > > //DISP=(OLD,DELETE), > > // > DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=4096) > > //SYSOUT DD SYSOUT=* > > //SYSPRINT DD SYSOUT=* > > //SYSINDD * > > PRINT INFILE(DD1) DUMP > > /* > > > > Thanks in advance > > > > -- > For IBM-MAIN subscribe / signoff / archive > access instructions, > send email to lists...@listserv.ua.edu > with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)
We are beginning the transition to COBOL V5.2 from V4.2 and exploring the new options available for debugging. We just discovered that the INITCHECK option is incompatible with OPTIMIZE(0). Using both options generates this warning-level message: IGYOS4021-W The "INITCHECK" option was discarded due to option conflict resolution. The "OPTIMIZE(0)" option took precedence. There is no restriction documented for INITCHECK in the V5.2 Programmer's Guide and no mention of this incompatibility in the section on incompatible compiler options either. Is this a maintenance issue? Are we missing a PTF or was there a PTF applied that introduced the restriction without updating the documentation? If the latter, a pointer to the PTF documentation would be appreciated. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blockchain
On 26 January 2017 at 12:43, Cannaerts, Jan wrote: > z/Series machines are not geared towards floating point operations the way > commodity GPUs, FPGAs, or purposely built BitCoin miners are. So you surely > would spend more money on electricity powering the machine than you'd gain > through mining BitCoins, as is already the case for GPUs. Bitcoin mining, except just possibly with special purpose hardware, can no longer be done at a profit unless your electricity is free. This could be solar PV (but will you pay off the capital cost?), or somewhere where hydroelectricity is heavily subsidized as a nighttime heating fuel, and so on. But of course there are other kinds of "free". Perhaps your office lease has electricity included, and says nothing about what you use it for. And of course there are all kinds of botnets and such out there that mine using their victims' compute power/electricity. But regardless, mining is slowly but surely on its way out as a direct money maker, by design. Five years ago you could make a little money using a simple GPU in a desktop PC; now that's impossible. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMC Mail domain
I do not believe this is correct. I do not think Listserv ever did this. I just subscribed from a new address and this is what my confirmation email looks like: -- From: The University of Alabama LISTSERV Server (16.0) [lists...@listserv.ua.edu] Sent: Thursday, January 26, 2017 5:39 PM To: Evans-Young, Darren Subject: Command confirmation request () Your command: SUBSCRIBE IBM-MAIN Big D has been received. You must now reply to this message (as explained... - Darren From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jesse 1 Robinson [jesse1.robin...@sce.com] Sent: Thursday, January 26, 2017 11:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HMC Mail domain This problem hits close to the heart of IBM-Main. I discovered a while back that a new email address could not successfully be registered from within the company network. This might be for a new person or for someone whose email address had changed. After considerable frustration, I learned that the IBM-Main confirmation email sent to a new registrant has a blank 'From' tag. Not structurally invalid, not unregistered. Empty. I assume that it had always been thus, but we hadn't tried to register a new email address in quite some time. Meanwhile our email nannies had implemented a new 'security' measure to reject any email that did not specify a From id. The sender is not verified AFAIK; there just has to be one. The argument is that this one action filters out a lot of true spam. So the confirmation email from IBM-Main looks like spam and is deleted without notice to the recipient. I take it that this is standard List server software behavior. I cannot imagine a business justification for it, but it requires that any new IBM-Main (or RACF-L) user ask for manual intervention from the List owner to add the user by hand. We are not a giant company, but we have several thousand email users. The idea of asking for an exemption for a literal handful of affected users is daunting, especially because the problem could be solved by a simple software change on the List server. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Thursday, January 26, 2017 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: EXTERNAL: Re: HMC Mail domain In my humble opinion this is not a problem with HMC but network/email folks in the organisation. Any HMC name and domain has to be somehow "authorized" within company network. So, *some* effort has to be done, irrespectively of the name of HMC. If I could choose I would pay much more effort into customisation of HMC email content, to make it more clear and comfortable for users. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMC Mail domain
I just also verified this with my gmail account. Valid From: tag. Darren From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jesse 1 Robinson [jesse1.robin...@sce.com] Sent: Thursday, January 26, 2017 11:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HMC Mail domain This problem hits close to the heart of IBM-Main. I discovered a while back that a new email address could not successfully be registered from within the company network. This might be for a new person or for someone whose email address had changed. After considerable frustration, I learned that the IBM-Main confirmation email sent to a new registrant has a blank 'From' tag. Not structurally invalid, not unregistered. Empty. I assume that it had always been thus, but we hadn't tried to register a new email address in quite some time. Meanwhile our email nannies had implemented a new 'security' measure to reject any email that did not specify a From id. The sender is not verified AFAIK; there just has to be one. The argument is that this one action filters out a lot of true spam. So the confirmation email from IBM-Main looks like spam and is deleted without notice to the recipient. I take it that this is standard List server software behavior. I cannot imagine a business justification for it, but it requires that any new IBM-Main (or RACF-L) user ask for manual intervention from the List owner to add the user by hand. We are not a giant company, but we have several thousand email users. The idea of asking for an exemption for a literal handful of affected users is daunting, especially because the problem could be solved by a simple software change on the List server. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Thursday, January 26, 2017 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: EXTERNAL: Re: HMC Mail domain In my humble opinion this is not a problem with HMC but network/email folks in the organisation. Any HMC name and domain has to be somehow "authorized" within company network. So, *some* effort has to be done, irrespectively of the name of HMC. If I could choose I would pay much more effort into customisation of HMC email content, to make it more clear and comfortable for users. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)
I would suggest getting 6.1 then converting. IBM made some changes that eliminate some situations that need coding changes. Should be the same license cost, just cost you install time. Be sure to convert to Country Multiplex / MSU licensing so you don't have a limited time before having to pay for 4.2 AND 5.2/6.1. On Thu, Jan 26, 2017 at 2:25 PM, Farley, Peter x23353 wrote: > We are beginning the transition to COBOL V5.2 from V4.2 and exploring the new > options available for debugging. > > We just discovered that the INITCHECK option is incompatible with > OPTIMIZE(0). Using both options generates this warning-level message: > > IGYOS4021-W The "INITCHECK" option was discarded due to option conflict > resolution. The "OPTIMIZE(0)" option took precedence. > > There is no restriction documented for INITCHECK in the V5.2 Programmer's > Guide and no mention of this incompatibility in the section on incompatible > compiler options either. > > Is this a maintenance issue? Are we missing a PTF or was there a PTF applied > that introduced the restriction without updating the documentation? If the > latter, a pointer to the PTF documentation would be appreciated. > > Peter > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. If > the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by e-mail > and delete the message and any attachments from your system. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 CKPT and Spool Size RFE
For best results, log in then click on the link. On Wed, Jan 25, 2017 at 1:50 PM, Carmen Vitullo wrote: > :( > Our apologies... > > The content you are trying to access is not available. Please try again later. > > > - Original Message - > > From: "Lizette Koehler" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Tuesday, January 24, 2017 3:23:49 PM > Subject: JES2 CKPT and Spool Size RFE > > If you like it, please vote for it. > > http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=100074 > > > This is requesting IBM to create a new command $DCKPTSIZE that would allow > shops > to issue it and JES2 respond with numbers of what would be needed. > > $DCKPTSIZE,BERTS=10 would request JES2 to see if the current sizes can > handle an increase to 100,000 Berts. If not, what would it take. > $DCKPTSIZE,BERTS=10,JOES=12,JNUMS=6000 could be another > variation > > > I am thinking the same code path used by the $T command which produces the > HASP > Message XX more 4K blocks is needed, might be able to be use. > > I suggested all JES2 resources should be allowed on this command that affect > the > size of the CKPT and/or Spool > > > Lizette Koehler > statistics: A precise and logical method for stating a half-truth > inaccurately > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)
Not my call, unfortunately. Mgmt decision already made more than several levels above me. If there are any docs out there (preferably slide-type presentations suitable for mgmt) with technical justification(s) that could help change the decision, I'd appreciate pointers. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Thursday, January 26, 2017 9:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W) I would suggest getting 6.1 then converting. IBM made some changes that eliminate some situations that need coding changes. Should be the same license cost, just cost you install time. Be sure to convert to Country Multiplex / MSU licensing so you don't have a limited time before having to pay for 4.2 AND 5.2/6.1. On Thu, Jan 26, 2017 at 2:25 PM, Farley, Peter x23353 wrote: > We are beginning the transition to COBOL V5.2 from V4.2 and exploring the new > options available for debugging. > > We just discovered that the INITCHECK option is incompatible with > OPTIMIZE(0). Using both options generates this warning-level message: > > IGYOS4021-W The "INITCHECK" option was discarded due to option conflict > resolution. The "OPTIMIZE(0)" option took precedence. > > There is no restriction documented for INITCHECK in the V5.2 Programmer's > Guide and no mention of this incompatibility in the section on incompatible > compiler options either. > > Is this a maintenance issue? Are we missing a PTF or was there a PTF applied > that introduced the restriction without updating the documentation? If the > latter, a pointer to the PTF documentation would be appreciated. > > Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)
Initially, the numeric / zero checks would not work like before. I know there is an parm to make it work like before in 6.1. Not sure if they applied it to 5.2. IBM Cobol Documentation page. Click on Version (6.1) then download Migration guide. Compare to 5.2 guide. http://www-01.ibm.com/support/docview.wss?uid=swg27036733 & download PDF. On Thu, Jan 26, 2017 at 8:37 PM, Farley, Peter x23353 wrote: > Not my call, unfortunately. Mgmt decision already made more than several > levels above me. > > If there are any docs out there (preferably slide-type presentations suitable > for mgmt) with technical justification(s) that could help change the > decision, I'd appreciate pointers. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mike Schwab > Sent: Thursday, January 26, 2017 9:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL V5.2 question: INITCHECK option incompatible with > OPTIMIZE(0)? (Msg IGYOS4021-W) > > I would suggest getting 6.1 then converting. IBM made some changes that > eliminate some situations that need coding changes. Should be the same > license cost, just cost you install time. Be sure to convert to Country > Multiplex / MSU licensing so you don't have a limited time before having to > pay for 4.2 AND 5.2/6.1. > > On Thu, Jan 26, 2017 at 2:25 PM, Farley, Peter x23353 > wrote: >> We are beginning the transition to COBOL V5.2 from V4.2 and exploring the >> new options available for debugging. >> >> We just discovered that the INITCHECK option is incompatible with >> OPTIMIZE(0). Using both options generates this warning-level message: >> >> IGYOS4021-W The "INITCHECK" option was discarded due to option conflict >> resolution. The "OPTIMIZE(0)" option took precedence. >> >> There is no restriction documented for INITCHECK in the V5.2 Programmer's >> Guide and no mention of this incompatibility in the section on incompatible >> compiler options either. >> >> Is this a maintenance issue? Are we missing a PTF or was there a PTF >> applied that introduced the restriction without updating the documentation? >> If the latter, a pointer to the PTF documentation would be appreciated. >> >> Peter > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. If > the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by e-mail > and delete the message and any attachments from your system. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blockchain
Jan Cannaerts wrote:
>z/Series machines are not geared towards floating point operations the way
>commodity GPUs, FPGAs, or purposely built BitCoin miners are.
True, but I don't think Rob Schramm is using a zSeries machine (z990, z890,
z900, or z800). I assume he's using one of the IBM z Systems. The
processors are different, better. I would not claim that IBM z13 processors
are *particularly* well suited to Bitcoin mining, but they are much better
suited than their zSeries predecessors were. They are not GPUs, but they
are more GPU-like.
They do very well indeed with Hyperledger Blockchain, by the way.
>So you surely would spend more money on electricity powering the machine
>than you'd gain through mining BitCoins, as is already the case for GPUs.
I don't think that assumption is correct, assuming the IBM z13, z13s, or
LinuxONE machine is otherwise powered up and performing some other
"reasonable" amount of work. Aside from static power save mode, they just
run, even when they're not doing much processing. They aren't like the
processors in your laptop, tablet computer, or smartphone that spend most
of their time in various lower power states.
Solely in terms of electricity consumption, an IBM z System running z/OS,
productively employed for some other work, might be the *ideal* part-time
Bitcoin mining platform.
>Moreover, what type of licensing do you have where you can use unused
cycles?
>We have MLC licensing, and as a result we get to use these unused cycles
when
>we need more processing power than we have defined.
Sure, but that's not every machine or even many of them. Let's suppose, for
example, that you have a 500 MSU Defined Capacity, set across all your
LPARs (group limit). So your licensing cannot go above 500 MSUs, and (let's
assume) you hit 500 MSUs every month. So 500 is both your minimum and your
maximum. Let's further suppose that you can predict, with high confidence,
that December 25 will be a low utilization day for at least 14 specific
hours. What happens if you slot in some Bitcoin mining into the first 10
hours of that 14 hour period, in the lowest WLM service class? Could that
Bitcoin mining workload detract from the "whitespace" above your 500 MSU
Defined Capacity? No, it cannot. It's a four hour rolling average, not a
fourteen hour rolling average.
Yes, maybe you have to avoid letting that discretionary workload bleed into
the final four hours before {markets open, branch offices open, the sun
rises, end of month processing starts, whatever}. That's quite possible to
do, though. All you need is a predictable "quiet" period at least somewhat
longer than four hours, that's all. Then you just tell your scheduler to
start a Bitcoin job (in the lowest service class) at the beginning of the
quiet period and stop it four hours before the end of the quiet period.
Loop, repeat. If that's 12 six hour intervals per year, great.
Lots of organizations have predictable "quiet" periods that are longer than
four hours. Sometimes they are three day weekend long periods, or longer.
If you want to be extra extra extra cautious, add in a 30 minute buffer. So
you tell your scheduler to stop the Bitcoin job four and one half hours
before the next "surge."
In short, no, Rob's idea is not crazy. Bitcoin mining probably is crazy, as
mentioned, but an unused mainframe processor cycle can be a *very* free one
to use. If you've got some discretionary workload that could be generating
some money, and it's free to run, why not slot it in? For that matter, even
if it's not free to run (and it's never free to run elsewhere that I can
think of), if running the workload generates another $2 million for the
company but it costs $680 to run, RUN IT! There's nothing toxi-magical
about 500 MSUs, or whatever your current limit is. Yes, I know, some crazy
people behave that way, but that "stick to the arbitrary MSU limit come
hell or high water!" behavior is what's crazy, not Rob's idea.
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
