Re: Speed up DASD copy
W dniu 2013-03-07 11:36, Miklos Szigetvari pisze: Hi We need to copy a large number of DASD volumes (from zDASD to DS6800). Any option to speed up? Seems CONCURRENT is not supported by the zDASD. For obvious reasons you cannot use FlashCopy or similar PiT techniques, the same for PPRC,SRDF, etc. So, you can try to optimize dss copy process, replace dss with something faster (IMHO marginal gain) or use specialized software for data migration - like TDMF. Note the last will not make the process faster, put the migration to the background. Of course it's not free. Last, but not least: for application data, which should be SMS-managed, you can use COPY in place while old volumes are in DISNEW state and new volumes are added to the storage groups. Similar technique can be used for DB2 data and other. As result you will have to move only few system volumes. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Speed up DASD copy
Hi Miklos, I'm making the assumption that your are referring to dfdss. The traditional way of speeding up dfdss (adrdssu) copy's (or dumps) is by using the OPT keyword. I believe the default is (3) which is 5 tracks read at at time. OPT(1) 1 track OPT(2) 2 tracks OPT(3) 5 tracks and OPT(4) 15 tracks read at at time. If you are doing a full volume copy i expect your sysin should look something like this:- COPY FULL ALLX ALLDATA(*) IDY(TS0002) ODY(XX12C0) - COPYVOLID PURGE OPT(4) or you may use INDD OUTDD for your volume selection Other criteria to consider, region size on your jobcard or pgm; number of available channels; whether you want to copy your disks when in use or not. Using a product like softek's tdmf will allow for in flight disk copys. If you don't ahve it, then dfdss should only be used for packs when not in use. With dfdss you need to cater for the volume ids on the source target volumes, so you may want to add steps to clip (ickdsf reformat) the source volume before the dfdss copy and clip the target volume to the original source name after the copy. This will keep it isolated and stop inadvertant access to the original source volume. Good luck! Dave *** Hi We need to copy a large number of DASD volumes (from zDASD to DS6800). Any option to speed up? Seems CONCURRENT is not supported by the zDASD. Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Speed up DASD copy
Miklos Szigetvari wrote: We need to copy a large number of DASD volumes (from zDASD to DS6800). Any option to speed up? Format/Init and then copy? :-D Sorry, but I can't resist above... Yes I saw Radoslaw's excellent comment. Seems CONCURRENT is not supported by the zDASD. Questions: Do you want a physical or logical copy? Or do you need something like peer-to-peer copy or a variant of it? Do you need instant copy? Copy while datasets are in use? IMHO, I think you should describe your copy needs in details? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Speed up DASD copy
Hi Thank you We will migrate from the zDASD to DS6800 . We need to make a physical copy while the systems are down. We will use a backup system and we would like to speed up something like this: COPY FULL INDYNAM(HFS039) OUTDYNAM(RESML1) COPYVOLID - ALLDATA(*) ALLEXCP ADMIN Funny but for the COPY , I didn't find the OPT keyword . 07.03.2013 12:43, Elardus Engelbrecht wrote: Miklos Szigetvari wrote: We need to copy a large number of DASD volumes (from zDASD to DS6800). Any option to speed up? Format/Init and then copy? :-D Sorry, but I can't resist above... Yes I saw Radoslaw's excellent comment. Seems CONCURRENT is not supported by the zDASD. Questions: Do you want a physical or logical copy? Or do you need something like peer-to-peer copy or a variant of it? Do you need instant copy? Copy while datasets are in use? IMHO, I think you should describe your copy needs in details? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Speed up DASD copy
Hi The dfdss accepting haply the OPT(4) keyword, the copy time dropped from 10 minutes to abut 7 minutes. The real copy will go from ESCON channels to FICON . We have to do this only once, as BusTech gave up the support for zDASD . Thank you On 07.03.2013 12:37, David Devine wrote: Hi Miklos, I'm making the assumption that your are referring to dfdss. The traditional way of speeding up dfdss (adrdssu) copy's (or dumps) is by using the OPT keyword. I believe the default is (3) which is 5 tracks read at at time. OPT(1) 1 track OPT(2) 2 tracks OPT(3) 5 tracks and OPT(4) 15 tracks read at at time. If you are doing a full volume copy i expect your sysin should look something like this:- COPY FULL ALLX ALLDATA(*) IDY(TS0002) ODY(XX12C0) - COPYVOLID PURGE OPT(4) or you may use INDD OUTDD for your volume selection Other criteria to consider, region size on your jobcard or pgm; number of available channels; whether you want to copy your disks when in use or not. Using a product like softek's tdmf will allow for in flight disk copys. If you don't ahve it, then dfdss should only be used for packs when not in use. With dfdss you need to cater for the volume ids on the source target volumes, so you may want to add steps to clip (ickdsf reformat) the source volume before the dfdss copy and clip the target volume to the original source name after the copy. This will keep it isolated and stop inadvertant access to the original source volume. Good luck! Dave *** Hi We need to copy a large number of DASD volumes (from zDASD to DS6800). Any option to speed up? Seems CONCURRENT is not supported by the zDASD. Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Speed up DASD copy
The PARALLEL keyword will cause DSS to start each copy as a sub task and run them together. Use SERIAL to single thread the copy if you wish. On Thu, 7 Mar 2013 13:34:15 +0100, Miklos Szigetvari miklos.szigetv...@isis-papyrus.com wrote: Hi The dfdss accepting haply the OPT(4) keyword, the copy time dropped from 10 minutes to abut 7 minutes. The real copy will go from ESCON channels to FICON . We have to do this only once, as BusTech gave up the support for zDASD . Thank you On 07.03.2013 12:37, David Devine wrote: Hi Miklos, I'm making the assumption that your are referring to dfdss. The traditional way of speeding up dfdss (adrdssu) copy's (or dumps) is by using the OPT keyword. I believe the default is (3) which is 5 tracks read at at time. OPT(1) 1 track OPT(2) 2 tracks OPT(3) 5 tracks and OPT(4) 15 tracks read at at time. If you are doing a full volume copy i expect your sysin should look something like this:- COPY FULL ALLX ALLDATA(*) IDY(TS0002) ODY(XX12C0) - COPYVOLID PURGE OPT(4) or you may use INDD OUTDD for your volume selection Other criteria to consider, region size on your jobcard or pgm; number of available channels; whether you want to copy your disks when in use or not. Using a product like softek's tdmf will allow for in flight disk copys. If you don't ahve it, then dfdss should only be used for packs when not in use. With dfdss you need to cater for the volume ids on the source target volumes, so you may want to add steps to clip (ickdsf reformat) the source volume before the dfdss copy and clip the target volume to the original source name after the copy. This will keep it isolated and stop inadvertant access to the original source volume. Good luck! Dave *** Hi We need to copy a large number of DASD volumes (from zDASD to DS6800). Any option to speed up? Seems CONCURRENT is not supported by the zDASD. Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article for the boss: COBOL will outlive us all
re: http://www.garlic.com/~lynn/2013c.html#11 Article for the boss: COBOL will outlive us all more cobol related trivia ... other spin-offs from the science center were companies that started offerring cp67 as commercial online service ... recent post in a.f.c http://www.garlic.com/~lynn/2013c.html#56 regarding RAMIS, NOMAD, FOCUS, etc ... i.e. original 4th gen languages ... all done on virtual machine (cp67 or vm370 based) online services nomad wiki http://en.wikipedia.org/wiki/Nomad_software from above: Another example of Nomad's power is illustrated by Nicholas Rawlings in his comments for the Computer History Museum about NCSS (see citation below). He reports that James Martin asked Rawlings for a Nomad solution to a standard problem Martin called the Engineer's Problem: give 6% raises to engineers whose job ratings had an average of 7 or better. Martin provided a dozen pages of COBOL, and then just a page or two of Mark IV, from Informatics. Rawlings offered the following single statement, performing a set-at-a-time operation, to show how trivial this problem was with Nomad: CHANGE ALL SALARY=SALARY*1.06 WHERE POSITION='ENG' AND AVG(INSTANCE(RATING)) GE 7 ... snip ... other trivia was that the original relational/sql was also done on vm370 ... mentioned in this recent post http://www.garlic.com/~lynn/2013c.html#32 REFRPROT History Question -- 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: Vary off path
In 4ee2851a2279b94cb70cd69b174106096ccda...@s1flokydce2kx01.dm0001.info53.com, on 03/06/2013 at 02:25 PM, Jousma, David david.jou...@53.com said: The CF command as issued as a z/OS command only configures it off to that LPAR. True, but you can broadcast a command to the entire sysplex. Or is each LPAR a monoplex? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
In 985915eee6984740ae93f8495c624c6c21f37ff...@jscpcwexmaa1.bsg.ad.adp.com, on 03/05/2013 at 02:18 PM, Farley, Peter x23353 peter.far...@broadridge.com said: Sometimes I wish they had not done away with TNL's (yeah, I know it's impractical in an age of electronic books, It is not, however, impractical to include updated documentation in the service stream. Has anybody submitted such a requirement to IBM? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
In 1631048133608148.wa.paulgboulderaim@listserv.ua.edu, on 03/05/2013 at 05:24 PM, Paul Gilmartin paulgboul...@aim.com said: If you don't find it in the Index, look very carefully through the entire catalogue. Keep in mind the traditional application of said catalog. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
In 9933210527218233.wa.paulgboulderaim@listserv.ua.edu, on 03/06/2013 at 08:20 AM, Paul Gilmartin paulgboul...@aim.com said: Why is this discussion taking place here ratner than on ASSEMBLER-LIST? Why not? It is on topic. F Assembler? Assembler VS? ITYM XF. Assembler VS was known as IFOX00, IIRC. Actually, IFOX00 was known as Assembler (XF). I once had a manual that explained the differences. One of the differences was that SETC no longer had an eight character limit. IMHO, IBM should have rewritten, e.g., CALL, to take advantage of that. It got left behind in a move. Bitsavers? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
In 1362595274.25094.yahoomai...@web181403.mail.ne1.yahoo.com, on 03/06/2013 at 10:41 AM, Lloyd Fuller leful...@sbcglobal.net said: In fact many of the feature upgrades from H Assembler to HLASM came from the SLAC mods descriptions as we wrote SHARE requirements for those features. In at least one case Greg's version was better than IBM's. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
how to trim connect direct 0d0a
how to trim the 0d during transfer from aix to host side, any connect direct exit can trim the 0d? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Speed up DASD copy
W dniu 2013-03-07 14:41, Matthew Stitt pisze: The PARALLEL keyword will cause DSS to start each copy as a sub task and run them together. Use SERIAL to single thread the copy if you wish. The same can be done by submitting several jobs in parallel, but actually we talk about quite poor device - a PC connected to some FBA disk array. This is bottleneck. IMHO the only feasible method is to copy as much as possible in the background. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ConnDir Secure+
Can anyone here answer question... Can the new ConnDir on M/F talk to a FTP/SSL on another M/F or does it need to be ConnDir to ConnDir?? -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how to trim connect direct 0d0a
On Thu, 7 Mar 2013 22:40:23 +0800, Tommy Tsui wrote: how to trim the 0d during transfer from aix to host side, any connect direct exit can trim the 0d? FTP does that routinely. Is FTP an alternative? I'm somewhat surprised that AIX uses 0D0A -- isn't AIX a UNIX-like system that I'd expect to use simply 0A? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JZOS batch launcher (JVMLDMxx) APF ?
Hello list, Has anyone ever tried to use the JZOS batch launcher to launch a chain that needs to be APF authorized ? It was linked (at least the version I am using from JDK 6.0.1) with AC(0) and I wonder if there is an APF authorized equivalent for it such as BPXBATA2 compared to BPXBATSL ? Maybe another way to get around it ? Thanks a lot, Jonathan RSD SA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ConnDir Secure+
From: Ron Wells ron.we...@slfs.com Date: 03/07/2013 09:02 AM Can anyone here answer question... Can the new ConnDir on M/F talk to a FTP/SSL on another M/F or does it need to be ConnDir to ConnDir?? SNIP ConnDir as in CONNECT:Direct? A/K/A: C:D, NDM, etc.? If that is correct, then no. There are specific communications protocols observed by C:D and FTP does not comply with them. Secure+ is the security portion of C:D, handling secure connections via the proprietary comm. protocols used by C:D. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ConnDir Secure+
Did I hear the other day that there is a Connect:Direct clone out there somewhere? (No disagreement with the answer below. C:D uses a proprietary protocol that has its roots in SNA.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Thompson Sent: Thursday, March 07, 2013 7:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ConnDir Secure+ From: Ron Wells ron.we...@slfs.com Date: 03/07/2013 09:02 AM Can anyone here answer question... Can the new ConnDir on M/F talk to a FTP/SSL on another M/F or does it need to be ConnDir to ConnDir?? SNIP ConnDir as in CONNECT:Direct? A/K/A: C:D, NDM, etc.? If that is correct, then no. There are specific communications protocols observed by C:D and FTP does not comply with them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ConnDir Secure+
From: Charles Mills charl...@mcn.org Date: 03/07/2013 10:14 AM Did I hear the other day that there is a Connect:Direct clone out there somewhere? (No disagreement with the answer below. C:D uses a proprietary protocol that has its roots in SNA.) Charles SNIPPAGE Yes, kinda, maybe. There was a C:D system (I forgot the platform) that was sold off years ago. They have recently contacted us and where those talks have gone, I do not know. Regards, Steve Thompson Formerly of MFT (C:D z/OS) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reality check on LOAD + Rexx LINKPGM
On 3/7/2013 10:23 AM, Shmuel Metz (Seymour J.) wrote: In 7215099641551385.wa.paulgboulderaim@listserv.ua.edu, on 03/06/2013 at 08:16 PM, Paul Gilmartin paulgboul...@aim.com said: Afterthought: If the module expects OS CALL linkage conventions, use LINKMVS rather than LINKPGM. No! Only use LINKMVS if you want halfword length fields prepended to the arguments; otherwise use LINKPGM. For the OP the target is CoBOL, presumably expecting character values. It should be possible to code the program(s) to detect how they are called and accept either form. I've done that in the past, but for assembler subroutines. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where current HLASM doc?
There were several of us working on the SHARE requirements. We tried to make a business case for the requirements that we needed. And, yes, some of Greg's changes did not get put into HLASM. A few we could not come up with a business case, and a few none of us were using and we did not know anyone that was using the feature so we did not burden IBM with those. As I remember, there were only one or two that John was not able to get implemented once we gave him the business case. And, yes, there were one or two that IBM implemented differently because it was the IBM way and not Greg's way. Lloyd - Original Message From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thu, March 7, 2013 9:24:34 AM Subject: Re: Where current HLASM doc? In 1362595274.25094.yahoomai...@web181403.mail.ne1.yahoo.com, on 03/06/2013 at 10:41 AM, Lloyd Fuller leful...@sbcglobal.net said: In fact many of the feature upgrades from H Assembler to HLASM came from the SLAC mods descriptions as we wrote SHARE requirements for those features. In at least one case Greg's version was better than IBM's. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reality check on LOAD + Rexx LINKPGM
On Thu, 7 Mar 2013 12:01:00 -0500, Gerhard Postpischil wrote: On 3/7/2013 10:23 AM, Shmuel Metz (Seymour J.) wrote: No! Only use LINKMVS if you want halfword length fields prepended to the arguments; otherwise use LINKPGM. For the OP the target is CoBOL, presumably expecting character values. It should be possible to code the program(s) to detect how they are called and accept either form. I've done that in the past, but for assembler subroutines. E.g. if the first hex digit is 0, assume the first two bytes are a length specification, up to 4095. BPXWDYN makes a similar judgment, and I got an astonishing result by passing it a PARM beginning with a character it was unprepared to handle. - gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Data Modeling/zTPM
Does anyone know of a way to anaylyze performance and perform data modeling similar to what zTPM does? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Data Modeling/zTPM
Hello: There are a couple of products from RES that provides this capability. Daisy and Daisy/DM. You can learn more about them on www.res-it.com. Regards, Mitch McCluhan, Legacy Moderization Consultant www.lcmg.us -Original Message- From: gsg gsg_...@yahoo.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Thu, Mar 7, 2013 9:28 am Subject: Data Modeling/zTPM Does anyone know of a way to anaylyze performance and perform data modeling imilar to what zTPM does? -- or IBM-MAIN subscribe / signoff / archive access instructions, end 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: Newer HLASM functions (was ...)
Regarding how you'd know, I have no idea. This wasn't done in an APAR. Regarding LR 15,R5 surely you provided the equate of R5 (or some macro did); fix/enhance the equate/macro. I see yregs, for example, which apparently is owned by DFSMS, has no facility for adding the register-size attribute. You might request that they do so. Regarding LR / CPYA vs LAE: They are not equivalent. Sometimes the difference doesn't matter; sometimes it does. Macros that are adjusted incrementally tend to stay on the conservative side. And the LR has existed forever. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
zDynaCap
My manager requested me to gather some information about a product called zDynaCap from ESAi (Enterprise Systems Associates Inc.). The rep supplied a link for a doc concerning the product. The article was short and not very in depth and claimed it could cut our IBM software costs. Has anyone installed zDynaCap? If so, was the install easy - Security, HMC levels, user interface ... Did the product deliver as adveritised? Was it actually worh it? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newer HLASM functions (was ...)
On 7 March 2013 07:53, Peter Relson rel...@us.ibm.com wrote: [With respect to GR32=NO|YES on IHASDWA] Regarding how you'd know, I have no idea. This wasn't done in an APAR. So how did *you* find out? Word of mouth, stumbled across it in the macro, or an internal doc of some sort? Or are you perhaps the one who updated IHASDWA? Regarding LR 15,R5 surely you provided the equate of R5 (or some macro did); fix/enhance the equate/macro. Right - I provided (in a macro) R5 EQU5GR32 which is fine for the LR, but of course not for the CPYA. I also have an equate for the ARs AR5 EQU5AR which will work with the CPYA but not the LR. I could remove the GR32, but then we're back to the beginning. The whole point is to allow the assembler to detect certain inappropriate uses of symbols. I see yregs, for example, which apparently is owned by DFSMS, has no facility for adding the register-size attribute. You might request that they do so. That would just break SETRP for more people! Regarding LR / CPYA vs LAE: They are not equivalent. Sometimes the difference doesn't matter; sometimes it does. Sure. Macros that are adjusted incrementally tend to stay on the conservative side. And the LR has existed forever. Well, I would've thought that in this case LAE would be more conservative than adding the CPYA (if in AR mode). The LR is already parameterized, and will emit an LGR if in 64-bit mode. The bottom line is that I can't see a way to both use the TYPECHECK(REGISTER) option, and use SETRP in AR mode with RUB=(...). (Well, I can, of course - I changed RUB=(R5) to RUB=(5), thus avoiding the warning, but also avoiding the checking. Ed/John - help me out here! What's the right way of doing this (on my part or IBM's)? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JZOS batch launcher (JVMLDMxx) APF ?
See this: http://www.ibm.com/developerworks/forums/thread.jspa?threadID=256965tstart=0 Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, Mar 7, 2013 at 9:39 AM, ESHEL Jonathan j.es...@rsd.com wrote: Hello list, Has anyone ever tried to use the JZOS batch launcher to launch a chain that needs to be APF authorized ? It was linked (at least the version I am using from JDK 6.0.1) with AC(0) and I wonder if there is an APF authorized equivalent for it such as BPXBATA2 compared to BPXBATSL ? Maybe another way to get around it ? Thanks a lot, Jonathan RSD SA -- 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: Data Modeling/zTPM
W dniu 2013-03-07 18:35, Mitch pisze: Hello: There are a couple of products from RES that provides this capability. Daisy and Daisy/DM. You can learn more about them on www.res-it.com. Regards, Mitch McCluhan, Legacy Moderization Consultant MODERIZATION? From the homepage: LCMG provides automated and custom solutions for the modernization and/or replacemet of exising appications acrss the enterprise, from z/OS to LUW and OS400 platforms. Oh, that's the moderization. Just REPLACEMET of EXISING APPICATIONS ACRSS the enterprise. (I couldn't resist) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Newer HLASM functions (was ...)
On 3/7/2013 10:51 AM, Tony Harminc wrote: The bottom line is that I can't see a way to both use the TYPECHECK(REGISTER) option, and use SETRP in AR mode with RUB=(...). (Well, I can, of course - I changed RUB=(R5) to RUB=(5), thus avoiding the warning, but also avoiding the checking. FWIW, this is what we do with all register specifications to IBM macros. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how to trim connect direct 0d0a
In 2497740495126867.wa.paulgboulderaim@listserv.ua.edu, on 03/07/2013 at 09:29 AM, Paul Gilmartin paulgboul...@aim.com said: I'm somewhat surprised that AIX uses 0D0A -- isn't AIX a UNIX-like system that I'd expect to use simply 0A? AIX is Unix, but the OP didn't specify what protocol or parameters he's using. IETF protocols normally use CRLF as a line terminator. I suspect that the OP is using FTP but specifying the transfer incorrectly, e.g., doing a binary transfer. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reality check on LOAD + Rexx LINKPGM
In 5138c7cc.4010...@valley.net, on 03/07/2013 at 12:01 PM, Gerhard Postpischil gerh...@valley.net said: For the OP the target is CoBOL, presumably expecting character values. AFAIK COBOL doesn't expect a halfword prefix on character parameters. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how to trim connect direct 0d0a
On Thu, 7 Mar 2013 17:46:57 -0500, Shmuel Metz (Seymour J.) wrote: on 03/07/2013 at 09:29 AM, Paul Gilmartin paulgboul...@aim.com said: I'm somewhat surprised that AIX uses 0D0A -- isn't AIX a UNIX-like system that I'd expect to use simply 0A? AIX is Unix, but the OP didn't specify what protocol or parameters he's using. IETF protocols normally use CRLF as a line terminator. I suspect that the OP is using FTP but specifying the transfer incorrectly, e.g., doing a binary transfer. If he were doing a binary transfer, the 0D would never have been added; if he were doing ASCII, the 0D would have been added by the sender and stripped by the receiver. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how to trim connect direct 0d0a
the file send from window server to aix with binary mode, 0d0a is reserved, finally the file send from aix to mainframe with ascii mode c:d, 0d is keep On 2013-3-8 上午6:56, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In 2497740495126867.wa.paulgboulderaim@listserv.ua.edu, on 03/07/2013 at 09:29 AM, Paul Gilmartin paulgboul...@aim.com said: I'm somewhat surprised that AIX uses 0D0A -- isn't AIX a UNIX-like system that I'd expect to use simply 0A? AIX is Unix, but the OP didn't specify what protocol or parameters he's using. IETF protocols normally use CRLF as a line terminator. I suspect that the OP is using FTP but specifying the transfer incorrectly, e.g., doing a binary transfer. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how to trim connect direct 0d0a
On Fri, 8 Mar 2013 08:48:58 +0800, Tommy Tsui wrote: the file send from window server to aix with binary mode, 0d0a is reserved, finally the file send from aix to mainframe with ascii mode c:d, 0d is keep On 2013-3-8 �W��6:56, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: Send it from Win to AIX in ASCII mode, then from AIX to mainframe in ASCII mode. Or, send it directly fro Win to mainframe in ASCII mode. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Me?
IEFSD095! In my early days (1968) working in POK, OS/360 System Design Department, I came across that very module -- and couldn't believe its blecherous code. It wasn't my assignment, but in not much time I rewrote it and ran speed tests, proving that my version was some multiple faster than the original. I couldn't get it integrated/shipped, of course, because of testing, regression testing, and other such fun reasons. Also of course, because OS wasn't spending that much time formatting large block letters on job output, so the overall improvement would have been minimal, at best. Ah, youth. Gerhard Postpischilgerh...@valley.net said: On 3/4/2013 12:56 AM, Scott Ford wrote: Anyone take into consideration the lack of skills nowdays. I am sure IBM is also running into this situation. They're sort of coming full circle. The programming team on OS/360 had to start from scratch, and many had experience only on the 7094. The word orientation shows in IEFSD095 (big letter routine) that did character manipulation using word instructions, and almost no character instructions (IIRC, they used an STC, but that was about it). -- Gabriel Goldberg, Computers and Publishing, Inc. g...@gabegold.com 3401 Silver Maple Place, Falls Church, VA 22042 (703) 204-0433 LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Me?
On Mar 7, 2013, at 10:56 PM, Jim Mulder wrote: SNIP_ In your honor, the blecherous code in IEFSD095 has been left unchanged, even as of z/OS 2.1 I remember that I used iefsd095 back in 1972 to create a short timers calendar, to mark off the number of days I had left in the ARMY. The captain was not amused. Ed Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
