Re: Modernizing the BCP code ?
Walt, Some of it would be difficult unless you embed at least some assembler in the Metal C stuff. For example, all date handling is removed from Metal C even the capability of getting the system date although that is trivial in assembler. There are other things that are missing from Metal C that probably do not need to be. Another example is that if you want to be able to allocate lasting memory (i.e. malloc) in Metal C, you have to embed some assembler; See the example in the Metal C user's guide. The example works, but there is assembler there (the load of register 12). Lloyd - Original Message From: Walt Farrell walt.farr...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Fri, April 13, 2012 11:11:35 PM Subject: Re: Modernizing the BCP code ? On Fri, 13 Apr 2012 15:05:57 -0400, Scott Ford scott_j_f...@yahoo.com wrote: Reading through this thread, quickly, it very obvious that certain exits must be in Assembler. So your kind of a captive audience. I am speaking of security type products. I have beem experimenting in C , not being a C heavy, it would be nice and desirable to do them in C . But sure if IBM supports ICHPWX01 in C ... Are there really system exits that -must be- in Assembler? Wouldn't Metal C work instead? (Yes, you might need to provide some control block mappings yourself, of course, but that really doesn't mean the language can't be used; just that it may be a bit inconvenient, depending on what you want to look at.) (And by the way, I'm pretty sure that Metal C would work for ICHPWX01 (RACF new password exit). You can even use System REXX if you want.) -- Walt -- 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: Modernizing the BCP code ?
On Sat, 14 Apr 2012 05:20:09 -0700, Lloyd Fuller leful...@sbcglobal.net wrote: Some of it would be difficult unless you embed at least some assembler in the Metal C stuff. For example, all date handling is removed from Metal C even the capability of getting the system date although that is trivial in assembler. There are other things that are missing from Metal C that probably do not need to be. Another example is that if you want to be able to allocate lasting memory (i.e. malloc) in Metal C, you have to embed some assembler; See the example in the Metal C user's guide. The example works, but there is assembler there (the load of register 12). Thanks, Lloyd. However, even with some assembler embedded in the Metal C source I would still consider that an exit written in Metal C. IBM even embeds assembler in PL/X on occasion, though they try to avoid it. And they still say the module is written in PL/X. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Modernizing the BCP code ?
Walt, That's great that you indicate they can be in Metal C, but I haven't seen any examples from IBM in there manuals. Also, it would be desirable to say 'yes' you can or 'no' you can't, it would help customers and us developers, IMHO. Examples are a great source for learning and helpful pointers. Regards Scott Ford Senior Systems Engineer www.identityforge.com On Apr 13, 2012, at 11:11 PM, Walt Farrell walt.farr...@gmail.com wrote: On Fri, 13 Apr 2012 15:05:57 -0400, Scott Ford scott_j_f...@yahoo.com wrote: Reading through this thread, quickly, it very obvious that certain exits must be in Assembler. So your kind of a captive audience. I am speaking of security type products. I have beem experimenting in C , not being a C heavy, it would be nice and desirable to do them in C . But sure if IBM supports ICHPWX01 in C ... Are there really system exits that -must be- in Assembler? Wouldn't Metal C work instead? (Yes, you might need to provide some control block mappings yourself, of course, but that really doesn't mean the language can't be used; just that it may be a bit inconvenient, depending on what you want to look at.) (And by the way, I'm pretty sure that Metal C would work for ICHPWX01 (RACF new password exit). You can even use System REXX if you want.) -- Walt -- 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: Modernizing the BCP code ?
Good idea, wrong address. Walt is retired. However the idea is really good. There many cases where IBM should prepare some sample exits (*). Even (as usually) in as is mode of responsibility. (*) I didn't say there are no sample exits from IBM. I said we lack some other exits. -- Radoslaw Skorupka Lodz, Poland W dniu 2012-04-14 17:26, Scott Ford pisze: Walt, That's great that you indicate they can be in Metal C, but I haven't seen any examples from IBM in there manuals. Also, it would be desirable to say 'yes' you can or 'no' you can't, it would help customers and us developers, IMHO. Examples are a great source for learning and helpful pointers. Regards Scott Ford Senior Systems Engineer www.identityforge.com On Apr 13, 2012, at 11:11 PM, Walt Farrellwalt.farr...@gmail.com wrote: On Fri, 13 Apr 2012 15:05:57 -0400, Scott Fordscott_j_f...@yahoo.com wrote: Reading through this thread, quickly, it very obvious that certain exits must be in Assembler. So your kind of a captive audience. I am speaking of security type products. I have beem experimenting in C , not being a C heavy, it would be nice and desirable to do them in C . But sure if IBM supports ICHPWX01 in C ... Are there really system exits that -must be- in Assembler? Wouldn't Metal C work instead? (Yes, you might need to provide some control block mappings yourself, of course, but that really doesn't mean the language can't be used; just that it may be a bit inconvenient, depending on what you want to look at.) (And by the way, I'm pretty sure that Metal C would work for ICHPWX01 (RACF new password exit). You can even use System REXX if you want.) -- Walt -- 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: Modernizing the BCP code ?
R.S. I have customers also asking for help , sample exits, we do security product work. So I know what IBM goes through also. But IBM being big Blue , how does one get someone to listen or pay attention to customer needs ? We are small and always listen to our customers. Fwiw Regards, Scott Ford Senior Systems Engineer www.identityforge.com On Apr 14, 2012, at 11:37 AM, R.S. r.skoru...@bremultibank.com.pl wrote: Good idea, wrong address. Walt is retired. However the idea is really good. There many cases where IBM should prepare some sample exits (*). Even (as usually) in as is mode of responsibility. (*) I didn't say there are no sample exits from IBM. I said we lack some other exits. -- Radoslaw Skorupka Lodz, Poland W dniu 2012-04-14 17:26, Scott Ford pisze: Walt, That's great that you indicate they can be in Metal C, but I haven't seen any examples from IBM in there manuals. Also, it would be desirable to say 'yes' you can or 'no' you can't, it would help customers and us developers, IMHO. Examples are a great source for learning and helpful pointers. Regards Scott Ford Senior Systems Engineer www.identityforge.com On Apr 13, 2012, at 11:11 PM, Walt Farrellwalt.farr...@gmail.com wrote: On Fri, 13 Apr 2012 15:05:57 -0400, Scott Fordscott_j_f...@yahoo.com wrote: Reading through this thread, quickly, it very obvious that certain exits must be in Assembler. So your kind of a captive audience. I am speaking of security type products. I have beem experimenting in C , not being a C heavy, it would be nice and desirable to do them in C . But sure if IBM supports ICHPWX01 in C ... Are there really system exits that -must be- in Assembler? Wouldn't Metal C work instead? (Yes, you might need to provide some control block mappings yourself, of course, but that really doesn't mean the language can't be used; just that it may be a bit inconvenient, depending on what you want to look at.) (And by the way, I'm pretty sure that Metal C would work for ICHPWX01 (RACF new password exit). You can even use System REXX if you want.) -- Walt -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
2012 VM Workshop registration now open
Solved the last few details -- you can now register for the workshop, and submit sessions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Modernizing the BCP code ?
On Fri, 13 Apr 2012 18:15:19 -0400, Farley, Peter x23353 wrote: Mind you, I wouldn't want to be the one supporting three different languages for all those DSECTS ... But it *would* be awfully helpful if IBM did it for us... :) I wonder again why, nowadays, IBM doesn't make a product of PL/X. I can imagine two reasons: o It would provide a relative advantage to competitors What competitors, anymore? And couldn't IBM control the distribution of PL/X by licensing, even as IBM controls the distribution of z/OS? o Anticipated revenues don't match anticipated cost to support. But IBM devoted considerable resource, instead, to METAL-C. Is METAL-C displacing any use of PL/X within IBM? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Modernizing the BCP code ?
Another consideration might be IBM doesn't need to worry about backward compatability or unreasonable user concerns and requirements. On Apr 14, 2012 12:57 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Fri, 13 Apr 2012 18:15:19 -0400, Farley, Peter x23353 wrote: Mind you, I wouldn't want to be the one supporting three different languages for all those DSECTS ... But it *would* be awfully helpful if IBM did it for us... :) I wonder again why, nowadays, IBM doesn't make a product of PL/X. I can imagine two reasons: o It would provide a relative advantage to competitors What competitors, anymore? And couldn't IBM control the distribution of PL/X by licensing, even as IBM controls the distribution of z/OS? o Anticipated revenues don't match anticipated cost to support. But IBM devoted considerable resource, instead, to METAL-C. Is METAL-C displacing any use of PL/X within IBM? -- 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: Secure FTP (Was: z/OS every two years)
On Sat, 2012-04-14 at 00:54 +, Gibney, Dave wrote: -Original Message- snip And, I've always found FTPS (granted no client identification certs yet) easier. None of that USS , sometimes called OMVS, perhaps properly called z/OS Unix System Services, involved :) Actually, I recently finished a sporadic effort to automount /u using ZFS. Now I can manage user's data in the zUnix arena. I may get back to trying ssh/sftp someday. If you implement the freely available SSH enhancements from Dovetailed Technologies, their sftp server can access the same z/OS legacy datasets and SPOOL (get to read a job's output, put to submit a job) as FTP. http://dovetail.com . Not only is the basic code free, you don't even need to register with them to download it. Literally no questions asked! Just download and implement. And it's fairly simple. If you want support, you can get that with a support contract. Dave Gibney Information Technology Services Washington State University -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Modernizing the BCP code ?
Bob: You are correct. Example: TSO code that won't be touched unless some BCP code breaks it. Even then some of it is so poorly documented IBM might just withdraw the broken part (example a TSO COMMAND (depending on what it is) ) The last major overhaul was the convertor interpreter they had to do that because of PSF and new JCL requirements needed for PSF). Ed On Apr 12, 2012, at 9:26 AM, Bob Shannon wrote: and seems to me the code is not very modern First, there are structures in the BCP code that are 40 years old. They haven't changed and are extremely difficult to change. Second, z/OS 1.13 will IPL on a z900/z800. This means the BCP can only use instructions supported by those processors. Third, according to yesterday's SOD, z/OS 2.1 requires at least a z9 processor. This implies the BCP in 2.1 can use instructions introduced on those processors. Bob Shannon Rocket Software -- 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
ADR938E - PROBLEM WITH FASTREPLICATION
G'Day, I am trying to figure out this problem. I checked the error message but I was unable to figure out what I should do or why the problem occurred. ADR918I (052)-DDTFP(01), FAST REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1 ADR938E (052)-DDTFP(01), FASTREPLICATION(REQUIRED) WAS SPECIFIED BUT FAST REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1 ADR006I (052)-STEND(02), 2012.105 02:34:11 EXECUTION ENDS Below is my jcl: //STEP1 EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440 //SYSPRINT DD SYSOUT=* //SYSIN DD * COPY FULL INDYNAM(RXTRS1) OUTDYNAM(@@883C) ALLE ALLD(*) - FASTREPLICATION(REQUIRED) FCNOCOPY DUMPCONDITIONING ADMIN PURGE Any suggestions? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Secure FTP (Was: z/OS every two years)
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John McKown Sent: Saturday, April 14, 2012 1:16 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Secure FTP (Was: z/OS every two years) On Sat, 2012-04-14 at 00:54 +, Gibney, Dave wrote: -Original Message- snip And, I've always found FTPS (granted no client identification certs yet) easier. None of that USS , sometimes called OMVS, perhaps properly called z/OS Unix System Services, involved :) Actually, I recently finished a sporadic effort to automount /u using ZFS. Now I can manage user's data in the zUnix arena. I may get back to trying ssh/sftp someday. If you implement the freely available SSH enhancements from Dovetailed Technologies, their sftp server can access the same z/OS legacy datasets and SPOOL (get to read a job's output, put to submit a job) as FTP. http://dovetail.com . Not only is the basic code free, you don't even need to register with them to download it. Literally no questions asked! Just download and implement. And it's fairly simple. If you want support, you can get that with a support contract. I looked at that more than once. I honestly don't remember what, if any, impediment stopped me for that route. Maybe merely time. Probably incomplete configuring of Ported Tools. :) I'll look again if I get a chance, but I think I'm even more of a one man show than you are. Currently I have to deal with our disk array going EOSL end of June by surprise. It's possible that the vendor did notify the guy who left abruptly, but I don't know. Dave Gibney Information Technology Services Washington State University -- John McKown Maranatha! -- 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
Fwd: Secret Computer Code Threatens Science: Scientific American
Interesting article, especially for those of us around 30(!) years ago for OCO battles. http://www.scientificamerican.com/article.cfm?id=secret-computer-code-threatens-science Some comments are scary -- like first one, 35 years geological research and not understanding this simple article. And others suggesting that software results be verified by rewriting software and comparing results. But not saying what to do when results compare unequal. Rewrite again and accept two-out-of-three? Maybe five-out-of-nine would suffice. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
