Re: FTP variable block dataset from z/OS to Windows and back
In 2099607434784895.wa.paulgboulderaim@listserv.ua.edu, on 01/10/2013 at 01:55 PM, Paul Gilmartin paulgboul...@aim.com said: ... notwithstanding that it's specified in RFC 959. RFC 959 allows 504 for STRU. -- 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: ICSF Master Key Management: TKE verus TSO Panels
Hello Radoslaw, thanks for your feedback QUESTIONS: -- 1. Does ICSF TSO panels method mean that the Key Management guys will have to logon to each lpar and load the new Master keys? Yes. Is it big pain? The Key management are not too happy, but they will just have to adapt life without the TKE workstation. As I said we only have a couple of legacy application crypto keys which are stabilized and we only used TKE to load new MK when we install a new machine. 2. Could we alternatively use the “pass phrase initialization utility” to reduce ICSF set-up time and then use our Change Management procedures to plan a new MK at a later date? Yes. A person performing the initialization still have to logon on each LPAR. Do you use the Passphrase Initialization or New Master Key entry method? regards Francis -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP variable block dataset from z/OS to Windows and back
Gil, It would seem so, but as I reported earlier in this thread, it doesn't work. Empty records are corrupted; I don't get the file back exactly as it started out. Sorry, I missed that. I suspect this is purely a z/OS flaw, I agree. If it does indeed work (or fail to work) as you describe, I would open a PMR with z/OS Comm Server. Best, Steven St.Jean -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, January 11, 2013 12:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FTP variable block dataset from z/OS to Windows and back On Thu, 10 Jan 2013 22:13:51 -0600, Ed Gould wrote: That is contrary to what I have experienced. What options? Certainly if you specify RDW. Otherwise, give an example, with hex dump. Of course, if you transfer z/OS to Z/OS with TYPE ASII, the RDWs are not transmitted, but reconstructed at the receiving end. On Thu, 10 Jan 2013 20:28:26 -0500, Steven St.Jean wrote: Gil, The ugly truth: STRU R 504 Unimplemented STRU type. Depending on what the OP wants to do with the file on the Windows system, it may not matter that it does not support STRU R. The important thing is that z/OS does. If the primary goal is what we used to call invertibility -- getting the file back exactly as it started out -- STRU R with binary should work. You just have to make sure you tell it to the z/OS side on both transfers. It would seem so, but as I reported earlier in this thread, it doesn't work. Empty records are corrupted; I don't get the file back exactly as it started out. I suspect this is purely a z/OS flaw, and it might occur even transferring directly z/OS to z/OS with STRU R. BTW, I understand how this process works with Windows client and z/OS server. Can it be done likewise with z/OS client and Windows server (which seemed to be the OP's requirement)? IOW, is there a LOCSTRU or LOCSITE STRU R type command to allow the Windows server to operate in BINARY mode and the z/OS client in RECORD? An immodest proposal: Does anyone want to write the requirement for: SITE AMATERSE and LOCSITE AMATERSE, and/or SITE TSOXMIT and LOCSITE TSOXMIT? -- gil -- 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: OMVS making a new root filesystem
Dear all, I had a cloned test system where I wanted to enable the OMVS functions. Up to now the system runs only in minimal OMVS mode. There is a chance that the cloning corrupted my root zFS. In order to verify this I wanted to setup another one as it was after normal installation. More or less I want to repeat only that step where to enable the full OMVS functionality. BR Florian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Master Key Management: TKE verus TSO Panels
Yes you have to initialize the keys in each LPAR but using CUT PASTE in your TN3270 emulator provided you have the keys laid out neatly in your document you are working from this only take a few minutes on each. We have never purchased the TKE due to the added cost and have 10 LPARs to update on an upcoming z196 to zEC12 migration this month and this doesn't really even amount to any significant time in our migration activities. The same process occurs at Disaster Recovery since we recover at IBM BCRS and so between CEC swaps every few years and annual DR exercise it’s a process the z/OS systems programmers are familiar with. Best Regards, Sam Knutson, GEICO System z Team Leader mailto:sknut...@geico.com (office) 301.986.3574 (cell) 301.996.1318 GEICO Operating Principles #1 Be the low-cost provider. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Francis van Zutphen Sent: Friday, January 11, 2013 2:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ICSF Master Key Management: TKE verus TSO Panels Hello ICSF System Programmers, Could you please assist/advise me on the following issue/concern. Due to the fact that we only have a couple of crypto keys to support legacy applications on our mainframe and because of cost saving exercise, we decided not to include the optional TKE workstation in our order of the new EC12 machine. This means we are reverting to ICSF TSO panels for Master Key(MK) management. We have 12 lpars connected to the Crypto Express co-processor and previously used TKE on the 1st lpar started in new hardware environment to load MK to all lpars. Now the Key Management guys are concerned that without the TKE workstation, loading new Master keys will be a prolonged process, i.e executing the new MK process x12 (on each lpar). Our Environment: ·Only DES Masterkey defined ·We have 3 categories of MKs : PRODUCTION, ACCEPTANCE, TEST ·FMID HCR7780 and HCR77A0 in progress ·Masterkey change every 2/3 years when new mainframe is installed OUTPUT OF ICSF COPROCESSOR MANAGEMENT PANELS COPROCESSOR SERIAL NUMBER STATUS AES DES ECC RSA P11 --- --- --- --- --- --- --- G00 9XX1 ACTIVE U A U U G01 9XX2 ACTIVE U A U U G02 9XX2 ACTIVE U A U U G03 9XX2 ACTIVE U A U U QUESTIONS: -- 1. Does ICSF TSO panels method mean that the Key Management guys will have to logon to each lpar and load the new Master keys? 2. Could we alternatively use the “pass phrase initialization utility” to reduce ICSF set-up time and then use our Change Management procedures to plan a new MK at a later date? regards Francis van Zutphen This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Master Key Management: TKE verus TSO Panels
We do use TKE, but I don’t think it matters for this conversation. But, correct me if I am wrong. We don’t assign a unique crypto domain per lpar. We have unique domains by environment for TECH, DEV and PROD environments. So the requirement for us is to load keys for each environment only per CPC. All lpars that share the same domain on the same CPC only need to be done on ONE of the systems. Even with a TKE, we still have to go into the ICSF dialogs and do the SET MK function, again, once per crypto domain, per CPC. If you assign unique domain to every lpar, then yes, you have to logon to each and every lpar. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Knutson, Sam Sent: Friday, January 11, 2013 8:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ICSF Master Key Management: TKE verus TSO Panels Yes you have to initialize the keys in each LPAR but using CUT PASTE in your TN3270 emulator provided you have the keys laid out neatly in your document you are working from this only take a few minutes on each. We have never purchased the TKE due to the added cost and have 10 LPARs to update on an upcoming z196 to zEC12 migration this month and this doesn't really even amount to any significant time in our migration activities. The same process occurs at Disaster Recovery since we recover at IBM BCRS and so between CEC swaps every few years and annual DR exercise it’s a process the z/OS systems programmers are familiar with. Best Regards, Sam Knutson, GEICO System z Team Leader mailto:sknut...@geico.com (office) 301.986.3574 (cell) 301.996.1318 GEICO Operating Principles #1 Be the low-cost provider. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Master Key Management: TKE verus TSO Panels
W dniu 2013-01-11 15:23, Jousma, David pisze: We do use TKE, but I don’t think it matters for this conversation. But, correct me if I am wrong. We don’t assign a unique crypto domain per lpar. We have unique domains by environment for TECH, DEV and PROD environments. So the requirement for us is to load keys for each environment only per CPC. All lpars that share the same domain on the same CPC only need to be done on ONE of the systems. Even with a TKE, we still have to go into the ICSF dialogs and do the SET MK function, again, once per crypto domain, per CPC. If you assign unique domain to every lpar, then yes, you have to logon to each and every lpar. Excuse me, are you sure that you are sharing crypto domains between LPARs? AFAIK it is simply impossible. Precisely, it is impossible to use the same domain number for the same crypto engine for different concurrently active LPARs. What is possible: - to share domain number between LPAR1 and LPAR2, but only one of them is activated - share domain number, between LPAR1 and LPAR2 which are concurrently active, but LPAR1 use CryptoEngine 1, while LPAR2 use CryptoEngine 2. - the LPARs reside on different CPCs. IMHO the most typical case is all LPARs use all crypto engines and all are (can be) active at the same time. In such scenario domains have to be unique. BTW: It is possible to assign more than 1 domain to a given LPAR, but z/OS (ICSF) can use one at a time. Change requires ICSF recycle. Regards -- 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
Re: ICSF Master Key Management: TKE verus TSO Panels
R.S, thanks for the clarification. I was confusing control domains and usage domains. We setup all our production lpars to be able to control all domains assigned to production lpars. But as you state, each lpar has a unique usage domain assigned. And then that’s where TKE comes in. I can load master key to multiple domains at once from a single lpar for all the control domains assigned to that lpar. Sorry to provide inaccurate information. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Friday, January 11, 2013 9:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ICSF Master Key Management: TKE verus TSO Panels W dniu 2013-01-11 15:23, Jousma, David pisze: We do use TKE, but I don’t think it matters for this conversation. But, correct me if I am wrong. We don’t assign a unique crypto domain per lpar. We have unique domains by environment for TECH, DEV and PROD environments. So the requirement for us is to load keys for each environment only per CPC. All lpars that share the same domain on the same CPC only need to be done on ONE of the systems. Even with a TKE, we still have to go into the ICSF dialogs and do the SET MK function, again, once per crypto domain, per CPC. If you assign unique domain to every lpar, then yes, you have to logon to each and every lpar. Excuse me, are you sure that you are sharing crypto domains between LPARs? AFAIK it is simply impossible. Precisely, it is impossible to use the same domain number for the same crypto engine for different concurrently active LPARs. What is possible: - to share domain number between LPAR1 and LPAR2, but only one of them is activated - share domain number, between LPAR1 and LPAR2 which are concurrently active, but LPAR1 use CryptoEngine 1, while LPAR2 use CryptoEngine 2. - the LPARs reside on different CPCs. IMHO the most typical case is all LPARs use all crypto engines and all are (can be) active at the same time. In such scenario domains have to be unique. BTW: It is possible to assign more than 1 domain to a given LPAR, but z/OS (ICSF) can use one at a time. Change requires ICSF recycle. Regards -- 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your
Re: Passing of Chris Mason reported
Chris was certainly without peer in his area of expertise of mainframe networking. And he was certainly passionate about matters related to his expertise, as we all can attest. There won't be another quite like him. RIP John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP variable block dataset from z/OS to Windows and back
On Fri, 11 Jan 2013 08:18:37 -0500, Steven St.Jean wrote: Gil, It would seem so, but as I reported earlier in this thread, it doesn't work. Empty records are corrupted; I don't get the file back exactly as it started out. Sorry, I missed that. I suspect this is purely a z/OS flaw, I agree. If it does indeed work (or fail to work) as you describe, I would open a PMR with z/OS Comm Server. WAD is highly likey for this. It's easy to suspect that there's a common subroutine to add record to target file, called for all transfer modes, that converts empty records to spaces. And that behavior may have been inherited from VM/CMS where empty records are strictly prohibited by the file system. And they might consider it an incompatible behavior. It might break end user code that does LH; BCTR; EX; MVC to copy variable length records. Same reason that ISPF/PDF changes empty records even with SET PRESERVE ON. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP variable block dataset from z/OS to Windows and back
I'm not sure if it is related, but the IBM C library has a wierd feature (bug) - search the IBM C/C++ Programmers Guide for _EDC_ZERO_RECLEN. Warning: the documentation is pretty confusing. On Fri, Jan 11, 2013 at 10:02 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Fri, 11 Jan 2013 08:18:37 -0500, Steven St.Jean wrote: Gil, It would seem so, but as I reported earlier in this thread, it doesn't work. Empty records are corrupted; I don't get the file back exactly as it started out. Sorry, I missed that. I suspect this is purely a z/OS flaw, I agree. If it does indeed work (or fail to work) as you describe, I would open a PMR with z/OS Comm Server. WAD is highly likey for this. It's easy to suspect that there's a common subroutine to add record to target file, called for all transfer modes, that converts empty records to spaces. And that behavior may have been inherited from VM/CMS where empty records are strictly prohibited by the file system. And they might consider it an incompatible behavior. It might break end user code that does LH; BCTR; EX; MVC to copy variable length records. Same reason that ISPF/PDF changes empty records even with SET PRESERVE ON. -- gil -- 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: FTP variable block dataset from z/OS to Windows and back
On Fri, 11 Jan 2013 10:27:38 -0600, Kirk Wolf wrote: I'm not sure if it is related, but the IBM C library has a wierd feature (bug) - search the IBM C/C++ Programmers Guide for _EDC_ZERO_RECLEN. Warning: the documentation is pretty confusing. Yah. This is an environment variable documented as affecting the z/OS UNIX commands CP and MV. What's truly dreadful is that the default is the less UNIX-like behavior. So FTP might be making an accommodation for this. How does this affect Co:Z? But, yes, bug. Although ANSI C waffles in order to accommodate RECFM=F and filesystems such as VM/CMS MDFS which tolerates neither empty files nor empty lines. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP variable block dataset from z/OS to Windows and back
WAD is highly likey for this. It's easy to suspect that there's a common subroutine to add record to target file, called for all transfer modes, that converts empty records to spaces. This might make sense for FB files, but not for VB, especially in binary mode. The FTP server has no grounds to decide that a space represents emptiness. An FTP server has no business using a common subroutine for all transfer modes. Data transformation is half the job. (I know; I used to be responsible for one.) And they might consider it an incompatible behavior. It might break end user code... If end-user code cannot handle empty VB records, the code would obviously have the same problem with original file. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, January 11, 2013 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FTP variable block dataset from z/OS to Windows and back On Fri, 11 Jan 2013 08:18:37 -0500, Steven St.Jean wrote: Gil, It would seem so, but as I reported earlier in this thread, it doesn't work. Empty records are corrupted; I don't get the file back exactly as it started out. Sorry, I missed that. I suspect this is purely a z/OS flaw, I agree. If it does indeed work (or fail to work) as you describe, I would open a PMR with z/OS Comm Server. WAD is highly likey for this. It's easy to suspect that there's a common subroutine to add record to target file, called for all transfer modes, that converts empty records to spaces. And that behavior may have been inherited from VM/CMS where empty records are strictly prohibited by the file system. And they might consider it an incompatible behavior. It might break end user code that does LH; BCTR; EX; MVC to copy variable length records. Same reason that ISPF/PDF changes empty records even with SET PRESERVE ON. -- gil -- 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: OT: IBM #1 in number of patents for 2012. It's 20th year in a row to do so.
By 'prior art' might you be suggesting 'copyright'? Graham Hobbs - Original Message - From: John Gilmore jwgli...@gmail.com Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, January 11, 2013 11:48 AM Subject: Re: OT: IBM #1 in number of patents for 2012. It's 20th year in a row to do so. A certain amount of IBM's patenting activity is defensive, designed to ensure that someone else will not be able to obtain a patent instead and thus be in a position to exact royalties or market a very similar product/near copy. Pharmaceutical and chemical companies do much the same thing by patenting a number of related compounds defensively, even though their interest is chiefly in just one of them. IBM also publishes a Disclosure Journal, available in libraries but not I think by subscription, in which it discloses the details of 'inventions' that it does not itself wish to patent in order to make it impossible for others to patent them later. (Patents can be invalidated if prior art can be shown to have existed when they were issued.) Patent quality is for these and other reasons an elusive notion; but patent people--many of them are hybrid lawyer-engineer types--mostly take the view that IBM's patents are of very high quality indeed. John Gilmore, Ashland, MA 01721 - USA -- 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
Problem with REXX using OMVS stuff.
Does anyone know of any reason why a subroutine in REXX can do an
allocation that gives RC=0 and then in the main routine an EXECIO fails
(RC=20), and a FREE DDN(xxx) (where xxx is the same DDName from the alloc)
fails saying that the DD is not allocated?
The subroutine is NOT using PROCEDURE, so things are not being hidden
(where EXPOSE would be needed...).
Granted, I have syscalls('ON) and that environment exists. And if I
hadn't done an ADDRESS TSO the EXECIO and FREE would fail with ye good
ole +++ RC(-3) +++ (Command not found).
And I do know that the allocation worked, because 3.4 shows the file with
all the attributes used on the allocate command.
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: Problem with REXX using OMVS stuff -- w/ code snippets
On Fri, 11 Jan 2013 14:53:24 -0600, Steve Thompson wrote:
[ ... ] EXECIO * DISKW DLBUT1 (OPEN)
ALLOC DSNAME('||dsname||') DDNAME(BLDUT1) OLD
IRX0555E The input or output file DLBUT1 is not allocated. It cannot be
opened for I/O.
IRX0670E EXECIO error while trying to GET or PUT a record.
+++ RC(20) +++
Sometimes they're easier than others.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem with REXX using OMVS stuff -- w/ code snippets
Well, I do see a typo in the DDname, which is one of the things I mentioned
in my last reply:
EXECIO * DISKW DLBUT1 (OPEN)
ALLOC DSNAME('||dsname||') DDNAME(BLDUT1) OLD
DLBUT1 vs. BLDUT1.
But what Paul just wrote could apply too.
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
On Fri, 11 Jan 2013 14:53:24 -0600, Steve Thompson sthomp...@us.ibm.com wrote:
OK, to answer a few questions:
It makes NO difference if I run it under ISPF (which is where it will be
once completed) or IKJEFT01 batch. SCP = z/OS 1.12
Here are the pieces you might want to see:
CALL RPTFILE
ADDRESS TSO
msg_val = MSG(ON)
TRACE I
EXECIO * DISKW DLBUT1 (OPEN)
And now for RPTFILE:
RPTFILE: NOP
ADDRESS TSO
msg_val = MSG(ON)
TRACE I
ALLOC DSNAME('||dsname||') DDNAME(BLDUT1) OLD
x = rc /* capture the ALLOC RC */
IF x 0 THEN DO
alloc_str = NEW CATALOG SPACE(1,3) CYLINDERS BLKSIZE(0) ,
|| LRECL(255) RECFM(V,B) DSORG(PS) RELEASE UNIT(3390)
IF diag THEN SAY ALLOCATE will use: alloc_str
ALLOC DSNAME('||dsname||') DDNAME(BLDUT1) || alloc_str
x = RC
TRACE N
END
ADDRESS SYSCALL
RETURN x
-
The ADDRESS SYSCALL in *this* case was not needed, because as you can
see the following code does an ADDRESS TSO right after coming back.
Here is the result of the working ALLOC:
OALLOC DSNAME('DLBUILD.some qualifiers') DDNAME(BLDUT1) OLD
367 *-* x = rc /**/
V0
And for the EXECIO:
274 *-* EXECIO * DISKW DLBUT1 (OPEN)
L EXECIO * DISKW DLBUT1 (OPEN)
IRX0555E The input or output file DLBUT1 is not allocated. It cannot be
opened for I/O.
IRX0670E EXECIO error while trying to GET or PUT a record.
+++ RC(20) +++
So I'm baffled. I am not using PROCEDURE in this subroutine, the code that
does use PROCEDURE is after all other non-procedure users in this source.
Anyone have any idea why the main line can't find the DCB (or DDNAME)?
Regards,
Steve Thompson
--
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: Problem with REXX using OMVS stuff -- w/ code snippets
As someone kindly pointed out to me offline (and copied to IBM-Main), I need to open an APAR against IEBEYEBALL. So, for those of you who have not seen the poster, I shall recreate it for you: DAM Mothers Against Dyslexia I confess, I am dyslexic and it makes things interesting with ATC. [Uh, 12345, that would be 30 degrees to the other left] And what is so bad about this is, I was doing copy and paste to keep this from happening and of course missed a place. Thank you all for your time. 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: Problem with REXX using OMVS stuff -- w/ code snippets
On Fri, 11 Jan 2013 15:03:51 -0600, Mark Zelden m...@mzelden.com wrote:
Well, I do see a typo in the DDname, which is one of the things I mentioned
in my last reply:
EXECIO * DISKW DLBUT1 (OPEN)
ALLOC DSNAME('||dsname||') DDNAME(BLDUT1) OLD
I like to use, when convenient:
signal on novalue
call BPXWDYN( 'alloc rtddn(MYDD) ...' )
'EXECIO 1 DISKR' MYDD '(...'
which makes such errors glaringly obvious. It also avoids the need
for random DD names which I've seen in some of your macros. Let
SVC 99 do the dirty work instead.
But what Paul just wrote could apply too.
Oh, about the other stuff, and the RC(-3), yes.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New Blog
On Fri, 11 Jan 2013 15:12:53 -0600, Mary Anne Matyaz maryanne4...@gmail.com wrote: For those interested, Marna Walle has a new blog on the SHARE website...you can read it at http://www.share.org/p/bl/bl/blogid=12 Enjoy! MA Thanks! If she builds it, they shall come. :-) -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E APPLY CHECK Wish
On Fri, 11 Jan 2013 15:19:45 -0600, Mark Zelden wrote: On Fri, 11 Jan 2013 15:12:31 -0600, Paul Gilmartin wrote: Is there a way, in APPLY CHECK GROUP, to see a list of the SYSMODs that will be selected via GROUPEXTEND or GROUP when the actual APPLY is performed? Why should there be? GROUPEXTEND implies extra checks and overhead SMP/E will go through automatically so you don't have to. Maybe not much difference on a small CSI (probably what you are used to dealing with), but in older less efficient SMP/E versions and slower processors, and going against a large z/OS CSI, it could add quite a bit of CPU and wall clock time. I was assuming that APPLY CHECK GROUPEXTEND SELECT( ... ) validates that all the HOLDs and REQs can be resolved, recursively. (And that inline JCLIN will be verified). Am I wrong? If I'm right, all I'm wishing for is an additional line in SMPOUT or SMPRPT for each indirectly selected SYSMOD. I'd not expect this to add quite a bit of CPU and wall clock time. I see no need to verify or report SYSMODs that are already APPLYed. Support has called me in on a problem where a customer is getting IEWL errors on some fairly old PTFs. Of course, we've tested them and we don't make mistakes, and no other customers have reported the problem, so it must be the customer's fault (Isn't that what vendors are supposed to say?); we're trying to reproduce the customer's situation, and any additional information we could get would help. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: IBM #1 in number of patents for 2012. It's 20th year in a row to do so.
Isn't if you writes program for say IBM, doesn't that mean they own it...and I assume patent it, right ? Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Jan 11, 2013, at 10:53 AM, John McKown john.archie.mck...@gmail.com wrote: Most likely. And, given current trends, the person (usually a company) with the patent doesn't really use it to actually _make_ anything. They just use it to get license fee from people who actually use it for something. This is known as a patent troll. Or, if the patent owner uses it to make something, they use the patent to stop a competitor from developing some alternative device. design patents. On Fri, Jan 11, 2013 at 9:48 AM, Graham Hobbs gho...@cdpwise.net wrote: So if somebody invents something, anything, it's likely already patented? Graham Hobbs -- Maranatha! John McKown -- 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: OT: IBM #1 in number of patents for 2012. It's 20th year in a row to do so.
John, Could one conclude then, that inventing a software piece, copyrighting it (thus on a Govt database thus a public domain), a third party can patent the invention and you could end up paying the third party to use your own software? I read your comments closely and the above cannot happen!+ ..? Graham - Original Message - From: John Gilmore jwgli...@gmail.com Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, January 11, 2013 12:49 PM Subject: Re: OT: IBM #1 in number of patents for 2012. It's 20th year in a row to do so. Graham, Prior art is a lawyer's term, not mine. If, say, I published a paper in 1977 describing a scheme for extracting the square root of a non-negative integer by successive subtraction, using the fact that n^2 is the sum of the first n odd integers, i.e., 2^2 = 4 = 1 + 3 3^2 = 9 = 1 + 3 + 5 4^2 = 16 = 1+ 3 + 5 + 7 5^2 = 25 = 1 + 3 + 5 + 7 + 9 . . . a later attempt to patent such a scheme would [almopst certainly] fail. This relation is due to Fr Marin Mersenne (1588-1648), but while no mathematical relation is itself patentable a device based upon it, which might otherwise be patentable, would not be if my paper describing such a device were known to the relevant Patent Office. Thus, while my paper might well be copyrighted (most published papers are), that is not the point; what is crucial is that the putative ' invention', being already in the public domain, is non-novel and thus not patentable. John Gilmore, Ashland, MA 01721 - USA -- 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
