Re: VTAM communication z/OS 2.2 and z/OS 1.4
If I understand the question correctly, I'd recommend Enterprise Extender (EE). It's likely to be the more future proof option in various ways, and that'll be helpful. EE is also proving to be broadly interoperable across long spans of time. z/OS 1.4 supported IPv6 fairly well but not for EE, so it looks like you'll have to use IPv4 on both ends, for the UDP connectivity that EE uses. It wasn't really until z/OS 2.1 that EE was fully IPv6 enabled. If IPv6 is a necessity (and probably even if not) then, going from memory (please double check this) you should be able to set up an IPv6 IPsec tunnel between z/OS 1.4 and z/OS 2.2 -- i.e. the tunnel gets established using IPv6 addresses at both ends -- and then run IPv4 EE across that tunnel. Bear in mind that the security characteristics of that IPsec tunnel will be governed by its lowest denominator: z/OS 1.4. Speaking of security, EE also supports SNA Session-Level Encryption (SLE) and always has, although I'd want more than that. SNA SLE only supports the DES and 3DES algorithms. The usual, wise advice applies here about trying to bring up z/OS 1.4 and the applications it's running to a supported z/OS release as expeditiously as possible. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing JESYSMSG size
For PDS members I already do that and, yes, it is very fast! However, in the current situation the customer is retrieving Endevor members and, for various reasons, they need to be saved in a short-lived catalogued data set. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: 07 March 2018 01:41 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Managing JESYSMSG size As this is your code, it may be worth it to use BPAM rather than do a separate allocation for each member. Will also save lots of CPU. On Mon, 5 Mar 2018 13:51:48 +0700 Robin Atwood wrote: :>Greg- :>The SVC 99s are under my control and that is very useful to know! :> :>Thanks :>Robin :> :>-Original Message- :>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Price :>Sent: 03 March 2018 10:10 :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: Re: Managing JESYSMSG size :> :>On 2018-03-02 9:53 PM, Robin Atwood wrote: :>> Is there anyway via :>> JES2 or SMS to suppress these messages? Preferably on a per-job basis :>> rather than globally :> :>Would MSGLEVEL=(n,0) do the trick? :> :>If the DYNALLOCs are under your control, you can request this in the relevant SVC 99 text unit. :> :>Cheers, :>Greg :> :>-- :>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 -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: Codepage
scott Ford wrote: >We are using EZACICTR..we build a message inside our STC and convert EBCDIC >data to ASCII data based on a Parm, I.e.; codepage=uk ...uk is in side the >EZACICTR the entry is selected data converted, then encrypted and a >socket-write issued to a Java server. Part of our message build for example >maybe create a list of RACF userids, at the very end we add a '~' to tell the >Java server that's the end of data. We have done used the COBOL codepage 1140 >for EBCDIC data..the Java server is using codepage 437. All characters are >good no problems. Using a different EBCDIC codepage from EZACICTR yields a >tilde on z/OS but not on the Java server..hence the problem.. Ok, I understand. Thanks. >Any ideas ? Perhaps you can generate all characters from x'00' to whatever limit there is and see what character yields a tilde? Sorry, I can't help here (I am not a Java guy...). If you can't get help, I believe you should submit a formal request to fix it? 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: Product license key program
Don't forget about sites needing to replace a mainframe with a newer model, or upgrading their existing hardware to faster processors or more processors within the unit (I.E. same device type but different model). On Tue, Mar 6, 2018 at 11:57 PM, Brian Westerman wrote: > The problem with just using a date, is that the software could be moved to > any machine and duplicated any number of times and you would never know about > it to keep it from being unlawfully duplicated without payment. > > This doesn't mean that you don't trust your clients. In effect, while some > might argue, it's really just like locking your car or your home or having a > bike lock. > > Lets say that you generate your software and the people at company "X" pay > the license until January of 2020. In the mean time, 40 people who used to > work for company "X", decide that it's s good that they want to take it > to their new site with them. That would be great if you got revenue from > that movement, but you can't unless they call you and tell you that they > moved the software and their "new" company would like to license it. Also, > maybe the people at company "X" decide that they want to defray the cost of > the software they licensed from you, so they sell copies on the internet to > other sites. It will run until January of 2020, so there is nothing to keep > it from happening. I'm not saying that every client is dishonest, but it > only takes one person to make it bad for you. Admittedly, this is probably a > bit far fetched, but it's late and I'm tired. :) > > On the other hand, if you had a check in your module for the CPU Serial > number, (and machine type or LPAR name, or any of several limiting factors), > the client is in no way harmed or inconvenienced, because it will operate as > before with no impediments, save that the software can't be "moved" without > your permission. > > This should not cause any problems with DR testing or a real disaster because > most, (if not all) DR sites run under VM and will simulate the serials and MT > for just this purpose. You can also check for running under VM and disallow > it (or generate warnings), but that is not normally necessary and gets away > from the point I'm making. > > Also, your key code needs to take into account that the site might have > multiple physical processors (separate mainframes), so you want to make sure > that your "key" code supports multiple entries. This will also be useful for > those sites that use "friend" arrangements for their DR sites (other > companies who share each other's sites as Disaster Recovery sites for each > other). > > You can/should also add code that temporarily allows the product to function > when the key doesn't match, for use as a trial or for when "stuff" happens > that the site for some reason needs to use the code on another box > "temporarily". You can limit it for a period of time, or number of uses, or > whatever you think is reasonable, it's your software, you make the rules, > while generating messages that let the site know in no uncertain terms that > the the license is not "currently valid". > > There are lots of nice features you can add to the key process, and you can > do as many vendors have and set up a web page to generate "emergency" keys > for, well emergencies. The reason is because "stuff happens" and no one > is happy if the product can't be used for some reasonable reason and they > can't contact the vendor until the next day because no one happens to be on > call that night. > > If you are going to implement keys, you might as well do it right and make > sure you test-test-test the process before you send it out to your client(s). > It's a good way to lose them if you mess up something like this. All sites > will understand the necessity of you having keys in your software, but no one > will understand if it isn't rock solid. It's such a little nit to implement > correctly, but all it takes is one error in the key generation program to > ruin your day. > > Brian > > > On Tue, 6 Mar 2018 21:02:37 +, Savor, Thomas (Alpharetta) > wrote: > >>Brian, >> >>Never thought about Using CPUID and/or machine type as part of a software key. >> >>Generally speaking we try to stay away from tying application to any kind of >>machine. >>Our application is typical Cobol/Asm, Batch/CICS and VSAM/DB2 system. >>Cobol 5 was first change in years that required major changes to our >>application. >>Usually a change to the Operating System has no effect on application >>executing properly. >> >>But having said that, since I didn’t know really what makes up a key and how >>they work, this is an interesting change in direction and thinking. >>Thanks for the ideas. >> >>And thanks for the ofrer of helpI will almost certainly need it. >> >>Thanks, >> >>Tom Savor >> >>-- >>For IBM-MAIN subs
Re: Product license key program
The problem with just using a date, is that the software could be moved to any machine and duplicated any number of times and you would never know about it to keep it from being unlawfully duplicated without payment. This doesn't mean that you don't trust your clients. In effect, while some might argue, it's really just like locking your car or your home or having a bike lock. Lets say that you generate your software and the people at company "X" pay the license until January of 2020. In the mean time, 40 people who used to work for company "X", decide that it's s good that they want to take it to their new site with them. That would be great if you got revenue from that movement, but you can't unless they call you and tell you that they moved the software and their "new" company would like to license it. Also, maybe the people at company "X" decide that they want to defray the cost of the software they licensed from you, so they sell copies on the internet to other sites. It will run until January of 2020, so there is nothing to keep it from happening. I'm not saying that every client is dishonest, but it only takes one person to make it bad for you. Admittedly, this is probably a bit far fetched, but it's late and I'm tired. :) On the other hand, if you had a check in your module for the CPU Serial number, (and machine type or LPAR name, or any of several limiting factors), the client is in no way harmed or inconvenienced, because it will operate as before with no impediments, save that the software can't be "moved" without your permission. This should not cause any problems with DR testing or a real disaster because most, (if not all) DR sites run under VM and will simulate the serials and MT for just this purpose. You can also check for running under VM and disallow it (or generate warnings), but that is not normally necessary and gets away from the point I'm making. Also, your key code needs to take into account that the site might have multiple physical processors (separate mainframes), so you want to make sure that your "key" code supports multiple entries. This will also be useful for those sites that use "friend" arrangements for their DR sites (other companies who share each other's sites as Disaster Recovery sites for each other). You can/should also add code that temporarily allows the product to function when the key doesn't match, for use as a trial or for when "stuff" happens that the site for some reason needs to use the code on another box "temporarily". You can limit it for a period of time, or number of uses, or whatever you think is reasonable, it's your software, you make the rules, while generating messages that let the site know in no uncertain terms that the the license is not "currently valid". There are lots of nice features you can add to the key process, and you can do as many vendors have and set up a web page to generate "emergency" keys for, well emergencies. The reason is because "stuff happens" and no one is happy if the product can't be used for some reasonable reason and they can't contact the vendor until the next day because no one happens to be on call that night. If you are going to implement keys, you might as well do it right and make sure you test-test-test the process before you send it out to your client(s). It's a good way to lose them if you mess up something like this. All sites will understand the necessity of you having keys in your software, but no one will understand if it isn't rock solid. It's such a little nit to implement correctly, but all it takes is one error in the key generation program to ruin your day. Brian On Tue, 6 Mar 2018 21:02:37 +, Savor, Thomas (Alpharetta) wrote: >Brian, > >Never thought about Using CPUID and/or machine type as part of a software key. > >Generally speaking we try to stay away from tying application to any kind of >machine. >Our application is typical Cobol/Asm, Batch/CICS and VSAM/DB2 system. >Cobol 5 was first change in years that required major changes to our >application. >Usually a change to the Operating System has no effect on application >executing properly. > >But having said that, since I didn’t know really what makes up a key and how >they work, this is an interesting change in direction and thinking. >Thanks for the ideas. > >And thanks for the ofrer of helpI will almost certainly need it. > >Thanks, > >Tom Savor > >-- >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: Running ISPDTLC in batch?
Apparently not! My bad. Exactly what I was looking for. Thank you! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running ISPDTLC in batch?
Did you google? I did https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54pc00/isppc17.htm. On 7/03/2018 12:36 PM, Michael Hochee wrote: We are automating a build procedure for a z/OS product and would like to run the ISPF Dialog Tag Language Conversion Utility (ISPDTLC), in batch. I did not find any evidence of a supported programming interface or 'batch' examples in the ISPF Dialog Tag Language Guide and Reference manual. Any suggestions would be much appreciated. -- 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
Running ISPDTLC in batch?
We are automating a build procedure for a z/OS product and would like to run the ISPF Dialog Tag Language Conversion Utility (ISPDTLC), in batch. I did not find any evidence of a supported programming interface or 'batch' examples in the ISPF Dialog Tag Language Guide and Reference manual. Any suggestions would be much appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Codepage
PMFJI here, but ISTM that something is wrong with your translate table(s). Character tilde is X'A1' in code page 1140 (aka 037), and tilde is X'7E' in both IEC-8859-1 (LATIIN-1) and in UTF-8. Doe the Java server not use either UTF-8 or IEC-8859-1? Does your translate to "ASCII" not convert the tilde to X'7E' on the way to the Java server? Translating IEC-8859-1 or UTF-8 at the Java server back to code page 285 (UK EBCDIC) on the way out from that server should result in the tilde becoming X'BC'. Does that conversion not happen? In other words, where in the process does the translation break down? Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of scott Ford Sent: Tuesday, March 6, 2018 6:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Codepage We are using EZACICTR..we build a message inside our STC and convert EBCDIC data to ASCII data based on a Parm, I.e.; codepage=uk ...uk is in side the EZACICTR the entry is selected data converted, then encrypted and a socket-write issued to a Java server. Part of our message build for example maybe create a list of RACF userids, at the very end we add a '~' to tell the Java server that's the end of data. We have done used the COBOL codepage 1140 for EBCDIC data..the Java server is using codepage 437. All characters are good no problems. Using a different EBCDIC codepage from EZACICTR yields a tilde on z/OS but not on the Java server..hence the problem.. Any ideas ? Regards, Scott On Mar 6, 2018, 1:16 PM -0500, Charles Mills , wrote: > Don't confuse glyphs with code points. ~ is perhaps a delimiter for humans > who are perceiving glyphs visually but not for software that is processing > code points in binary. It would facilitate clearer thinking to say "we are > using x'something' (what? My poor old yellow card does not even have ~) as a > delimiter, and then translating that to ASCII before sending it to software > which expects the message to be delimited with x'something'." > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Elardus Engelbrecht > Sent: Tuesday, March 6, 2018 9:46 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Codepage > > scott Ford wrote: > > I see that J R replied to you, but I am still really confused about your > post. Since this is about code page, I am probably on a different [code] page > ... (yes, yes, that was an intended crruel pun and I will not turn a new > page, mind you... ;-D ) > > > > I need some help on localization for codepages. The issue is we use a '~' > > as a end of messages delimiter. > > Ouch Where is that delimiter '~' and in what code page is that? In EBCDIC > or ASCII? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Codepage
We are using EZACICTR..we build a message inside our STC and convert EBCDIC data to ASCII data based on a Parm, I.e.; codepage=uk ...uk is in side the EZACICTR the entry is selected data converted, then encrypted and a socket-write issued to a Java server. Part of our message build for example maybe create a list of RACF userids, at the very end we add a '~' to tell the Java server that's the end of data. We have done used the COBOL codepage 1140 for EBCDIC data..the Java server is using codepage 437. All characters are good no problems. Using a different EBCDIC codepage from EZACICTR yields a tilde on z/OS but not on the Java server..hence the problem.. Any ideas ? Regards, Scott On Mar 6, 2018, 1:16 PM -0500, Charles Mills , wrote: > Don't confuse glyphs with code points. ~ is perhaps a delimiter for humans > who are perceiving glyphs visually but not for software that is processing > code points in binary. It would facilitate clearer thinking to say "we are > using x'something' (what? My poor old yellow card does not even have ~) as a > delimiter, and then translating that to ASCII before sending it to software > which expects the message to be delimited with x'something'." > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Elardus Engelbrecht > Sent: Tuesday, March 6, 2018 9:46 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Codepage > > scott Ford wrote: > > I see that J R replied to you, but I am still really confused about your > post. Since this is about code page, I am probably on a different [code] page > ... (yes, yes, that was an intended crruel pun and I will not turn a new > page, mind you... ;-D ) > > > > I need some help on localization for codepages. The issue is we use a '~' > > as a end of messages delimiter. > > Ouch Where is that delimiter '~' and in what code page is that? In EBCDIC > or ASCII? > > -- > 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: CA Root CA Certificates Redux
And check out the Certificate sessions at SHARE next week. Go to http://bit.ly/2FZjkIg and search on Certificates. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Tuesday, March 6, 2018 12:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CA Root CA Certificates Redux The WSC Flash has been updated, and you can find it here: http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10884 The only change is that we recommend: 1. Getting both the DigiCert root CA certificates and installing them 2. Doing that before April 2018. If the short story works for you, here are the certificates we recommend you obtain and install: a. The “DigiCert Global Root CA” certificate, is available from https://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt. For your reference, the certificate has this serial number: 083BE056904246B1A1756AC95991C74A. b. The “DigiCert Global Root G2” certificate is available at https://www.digicert.com/CACerts/DigiCertGlobalRootG2.crt, and its serial number is: 033AF1E6A711A9A0BB2864B11D09FAE5. Right now, this seems likely to let everyone to get on with their lives and not worry about the details. But currently understood dates are included in the Flash, for the curious. Some of them might change. Once they are carved in stone we can do one last update. Getting this to this point involved what seemed to be an incredible number of people working behind the scenes. Clearly, we should all have started on it sooner. Sorry for the churn. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- 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: Product license key program
Brian, Never thought about Using CPUID and/or machine type as part of a software key. Generally speaking we try to stay away from tying application to any kind of machine. Our application is typical Cobol/Asm, Batch/CICS and VSAM/DB2 system. Cobol 5 was first change in years that required major changes to our application. Usually a change to the Operating System has no effect on application executing properly. But having said that, since I didn’t know really what makes up a key and how they work, this is an interesting change in direction and thinking. Thanks for the ideas. And thanks for the offer of helpI will almost certainly need it. Thanks, Tom Savor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CA Root CA Certificates Redux
The WSC Flash has been updated, and you can find it here: http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10884 The only change is that we recommend: 1. Getting both the DigiCert root CA certificates and installing them 2. Doing that before April 2018. If the short story works for you, here are the certificates we recommend you obtain and install: a. The “DigiCert Global Root CA” certificate, is available from https://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt. For your reference, the certificate has this serial number: 083BE056904246B1A1756AC95991C74A. b. The “DigiCert Global Root G2” certificate is available at https://www.digicert.com/CACerts/DigiCertGlobalRootG2.crt, and its serial number is: 033AF1E6A711A9A0BB2864B11D09FAE5. Right now, this seems likely to let everyone to get on with their lives and not worry about the details. But currently understood dates are included in the Flash, for the curious. Some of them might change. Once they are carved in stone we can do one last update. Getting this to this point involved what seemed to be an incredible number of people working behind the scenes. Clearly, we should all have started on it sooner. Sorry for the churn. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing JESYSMSG size
As this is your code, it may be worth it to use BPAM rather than do a separate allocation for each member. Will also save lots of CPU. On Mon, 5 Mar 2018 13:51:48 +0700 Robin Atwood wrote: :>Greg- :>The SVC 99s are under my control and that is very useful to know! :> :>Thanks :>Robin :> :>-Original Message- :>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Price :>Sent: 03 March 2018 10:10 :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: Re: Managing JESYSMSG size :> :>On 2018-03-02 9:53 PM, Robin Atwood wrote: :>> Is there anyway via :>> JES2 or SMS to suppress these messages? Preferably on a per-job basis :>> rather than globally :> :>Would MSGLEVEL=(n,0) do the trick? :> :>If the DYNALLOCs are under your control, you can request this in the relevant SVC 99 text unit. :> :>Cheers, :>Greg :> :>-- :>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 -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA-TSS Question
I have downloaded the latest 2811 page document. In the product enhancements section, on page 98: Data Set Encryption Support (RO97892) New z/OS DFSMS capabilities for data encryption require key labels when allocating encrypted data sets. These labels identify a protected data key in the ICSF key repository (CKDS). A new field (DSKEY) in ACIDs contains the ICSF key label to use for encryption. The following keywords are now available for managing keys and labels: SYMCPACFWRAP (see page 742) makes keys eligible to be rewrapped (protected) by CP Assist for Cryptographic Functions (CPACF). SYMCPACFRET (see page 741) determines whether ICSF can return a key in a wrapped (protected) form. DSKEY (see page 518) specifies the key label that encrypts/decrypts data in the ICSF cryptographic key data set (CKDS). CRITERIA (see page 489) (used with PERMIT) defines criteria to determine a user's access to a resource (such as a key label). Tom Chicklon - > Probably need to pull the latest TSS doc and look for changes in there. 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: VTAM communication z/OS 2.2 and z/OS 1.4
Tony, Thanks.. that is what I was looking for. Rob Schramm On Thu, Mar 1, 2018, 3:45 PM Cieri, Anthony wrote: > > You might get more feedback using the listserver > ibmtc...@vm.marist.edu > > More Communication Server folks hang out there > > > For my 2 cent...I am going strictly by memory here... > > I believe that more of the changes in Comm. Server (VTAM) between > z/OS 1.4 and current were in the realm of APPN/EE/HPR. If you chose EE, you > would be doing all of the aforementioned in VTAM. It is likely that EE > connections are possible between the 1.4 system and current, however, there > were some enhancements along the way that are NOT compatible with "older" > versions of VTAM. HPRSESLIM is one that comes to mind. If the 1.4 VTAM does > NOT support HPRSESLM (I don't recall exactly when it was introduced), then > if it is ENABLED in the VTAMOPTS of the current system, it would prevent > the connection from being established. > > If you chose CTC (MPC) for the connections, you could use Subarea > SNA (CDRMs). Of course, it is NOT the IBM preferred choice, but it is > stable and it is definitely supported at the z/OS 1.4 level of VTAM. There > will be some setup and coordination involved. The amount will depend upon > the number of systems you have to connect to the CMC. > > > Hth > Tony > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Rob Schramm > Sent: Monday, February 26, 2018 4:47 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: VTAM communication z/OS 2.2 and z/OS 1.4 > > What I want to do is run a z/OS 2.2 system as a CMC. Currently, there is > no connection between my z/OS 2.2 system and the z/OS 1.4 systems. My > concern is whether the z/OS 1.4 systems will be able to communicate with > the z/OS 2.2 system across CTCs. Or if it would be better to attempt to run > the communication across EE. All of these system are in the same physical > CEC. > > Thanks, > Rob Schramm > > > > > Rob Schramm > Senior Systems Consultant > > > On Sat, Feb 24, 2018 at 12:30 AM, Brian Westerman < > brian_wester...@syzygyinc.com> wrote: > > > I'm not sure what you are getting at. If you have a z/OS 1.4 system > > connected via EE (or a "real" CTC connection) to a 2.2 system and you > > tn3270 into that new(er) system, then every EE (or CTC connected, (i.e. > > cross domain)) application that is defined to that new(er) system > > (even if cross domain to the old box) is available. I think what you > > are trying to get at is that IF your old system doesn't support TCP/IP > > but can be connected to a new(er) system that does support both EE (or > > a CTC connection to the older box) and TCP/IP can you get to the VTAM > > applications that are available to the older system via the > > connections between the old system and new system, then the answer is > > yes. But since z/OS 1.4 also supported TCP/IP you don't need the > > other new(er) system for that. > > > > How you get INTO the system (any system) via TCP then any (VTAM) > > applications are available once you are there are available whether > > the connection is through a physical CTC between the two systems or EE > > (which can use IP). > > > > So I'm a little confused by the question. Just because you can't > > directly connect to the CICS region on the old(er) system via TCP, > > doesn't mean that you can't get to it via a TCP connected device. > > That's what the emulators are for. But maybe that's not your question > either. > > > > Sorry that I can't help any more without some clarifications. > > > > Brian > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA-TSS Question
These may be of interest: CA opened a problem: https://support.ca.com/us/download-center/problem-detail.html?docid=650097&productcd=TSSMVS&problemnbr=9937 And has an enhancement PTF: https://support.ca.com/us/download-center/solution-detail.html?docid=650087&os=OS&aparno=RO97892 I've downloaded the PTF, but not much in its hold data to give any hints as to how to use it. Enhancement Description: z/OS DFSMS is providing a simple approach to enable extensive encryption of data at rest for data on disk through DFSMS access methods. Security and Storage Administrators who are required to protect customer data can leverage the z Systems hardware encryption for data at rest through existing policy management without application changes. Probably need to pull the latest TSS doc and look for changes in there. Tom Chicklon -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steely.Mark Sent: Tuesday, March 06, 2018 1:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CA-TSS Question **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** We are z/OS v2.2 and CA-TSS V16. Does CA-TSS support the encryption key label in the DFP segment. This is the sample for RACF. /*---*/ /* Specify the encryption key label in the DFP segment. */ /*---*/ ALTDSD 'EYSHA.ICSF.ENCRYPT.ME.*' + DFP(DATAKEY(DATASET.EYSHA.ICSF.ENCRYPT.ME.ENCRKEY.0001)) All my searches came up empty. Any help would be appreciated. Thank You *** Disclaimer *** This communication (including all attachments) is solely for the use of the person to whom it is addressed and is a confidential AAA communication. If you are not the intended recipient, any use, distribution, printing, or copying is prohibited. If you received this email in error, please immediately delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** 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: FDRMOVE sample jcl
>From a 2015 SHARE presentation:
>https://share.confex.com/share/124/.../17134%20-%20History%20of%20DFSMS.pdf
>It is a fun trip down memory lane.
I do remember a toleration PTF in June 1988 that prevented corruption of the
MVS/XA 2.2 ICF catalogs when you went back from testing MVS/ESA 3.0e (it
expanded some fields that the XA ICFCATs could not handle). Dang...almost 30
years ago! I can't be that old, can I? Where has the time gone? :-(
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Seymour J Metz
Sent: Tuesday, March 06, 2018 12:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
My recollection is that DFSMS came in as a program product for MVX/XA,
replacing DFP and several other packages.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Richards, Robert B.
Sent: Tuesday, March 6, 2018 6:17 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: FDRMOVE sample jcl
PMFJI
Just about everyone who posted on this topic had portions of their reply
somewhat in error. I might as well. :-)
If my memory serves and I do not fall into the same memory lapses as the rest
of you... circa the first release of OS/390, IBM started rebranding everything
under the DFP family to be known as DFSMSxxx. DF/DSS was no longer a product.
It was to be known as DFSMSdss. IIRC, DFHSM and DFRMM stopped being their own
products at the V2R6 level. Other former DFP products followed the same
convention: DFSMSdfp, DFSMShsm and DFSMSrmm. Integration was the reason for the
season, easier for IBM to support. DFSORT and ICKDSF remained viable with their
own branding.
As previously posted, IFAPRDxx controls whether products are enabled or not,
but I believe DFSMShsm, DFSMSdss and DFSMSrmm are shipped with every order. If
the STATE is set to ENABLED, you can use it (and start paying for it if you
weren't already). You do not DELETE those entries, you just set them to
DISABLED.
Finally ADRDSSU is a PROGRAM and not a product.
As to IDP, their suite of FDR products are very good and in some cases (but not
all) better than the IBM equivalents. Horses for courses. At the time, IBM's
integration of the DFSMS family into the OS made OS upgrades much simpler. Plus
IDP was late in delivering FDR 5.0 as the first SMS-capable release.
I'll stop now. SHIELDS UP! :-)
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of PINION, RICHARD W.
Sent: Monday, March 05, 2018 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
I'm not necessarily disagreeing with you, but DSS has a separate entry in
IFAPRDxx. I said, we're not paying for it. But we are until we can convert
application level backups to use FDRAPPL. But, if what you say is true, then
maybe applications can continue to use DSS. I'm not the person who keeps up
with the contracts and licensing.
PRODUCT OWNER('IBM CORP')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DFSMSDSS)
STATE(ENABLED)
PRODUCT OWNER('IBM CORP')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DFSMSHSM)
STATE(DISABLED)
PRODUCT OWNER('IBM CORP')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DFSMSRMM)
STATE(ENABLED)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Carmen Vitullo
Sent: Monday, March 05, 2018 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
[External Email]
HSM and RMM are other payable products/services under the DF/SMS service, but
DF/DSS 'data set services' are not payable services or product, its part of the
base or base + features.
Carmen Vitullo
- Original Message -
From: "RICHARD W. PINION"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, March 5, 2018 1:34:50 PM
Subject: Re: FDRMOVE sample jcl
DF/DSS & HSM can be deleted from the list of IBM products, and thus not be
charged for them. In our shop, we have FDR/ABR/CPK and pay for those, but we
not do pay for DF/DSS & HSM.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Carmen Vitullo
Sent: Monday, March 05, 2018 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
[External Email]
It BEEN a part of DPF for so many years, I don't order DFS services or ADRDSSU
separately or get charged for these services.
I know most folks, if they get use to using FDR they'd rather use FDR for some
functions, I know you can copy/move using ADRDSSU and once you have some good
JCL and control cards (I use ISMF to create some samples) its quite easy, but
so is FDR if you're use to it.
Carmen Vitullo
- Original Message ---
Re: Codepage
Don't confuse glyphs with code points. ~ is perhaps a delimiter for humans who are perceiving glyphs visually but not for software that is processing code points in binary. It would facilitate clearer thinking to say "we are using x'something' (what? My poor old yellow card does not even have ~) as a delimiter, and then translating that to ASCII before sending it to software which expects the message to be delimited with x'something'." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Tuesday, March 6, 2018 9:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Codepage scott Ford wrote: I see that J R replied to you, but I am still really confused about your post. Since this is about code page, I am probably on a different [code] page ... (yes, yes, that was an intended crruel pun and I will not turn a new page, mind you... ;-D ) >I need some help on localization for codepages. The issue is we use a '~' as a >end of messages delimiter. Ouch Where is that delimiter '~' and in what code page is that? In EBCDIC or ASCII? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CA-TSS Question
We are z/OS v2.2 and CA-TSS V16. Does CA-TSS support the encryption key label in the DFP segment. This is the sample for RACF. /*---*/ /* Specify the encryption key label in the DFP segment. */ /*---*/ ALTDSD 'EYSHA.ICSF.ENCRYPT.ME.*' + DFP(DATAKEY(DATASET.EYSHA.ICSF.ENCRYPT.ME.ENCRKEY.0001)) All my searches came up empty. Any help would be appreciated. Thank You *** Disclaimer *** This communication (including all attachments) is solely for the use of the person to whom it is addressed and is a confidential AAA communication. If you are not the intended recipient, any use, distribution, printing, or copying is prohibited. If you received this email in error, please immediately delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Codepage
Take a look at the sample EZACICTR in TCPIP.SEZAINST. This includes lots of translate tables and allows you to specify the required table by name. Ray -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J R Sent: 06 March 2018 16:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Codepage >From an ASCII v EBCDIC standpoint, x'00' is NUL on both sides. Why not use it >as your end of message delimiter. Of course, you haven't given the complete picture. What else is in the message stream? Is it text only? Are there any binary fields included? Control fields? Etc? > On Mar 6, 2018, at 09:54, scott Ford wrote: > > All, > > I need some help on localization for codepages. The issue is we use a '~' as > a end of messages delimiter. We have a customer wanting to use a different > code page . > Ebcdic codepage 285 to ascii codepage 437 .. We place a '~' which is a > x'A1' which inside the normal Ebcdic 1140 codepage is x'7E', in 285 it is > x'BC' which isn't translating . We can't use national language support yet, > so we have been using a translate table ezacic04 from CICS sockets. > > > Regards, > Scott > > -- > 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 -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FDRMOVE sample jcl
My recollection is that DFSMS came in as a program product for MVX/XA,
replacing DFP and several other packages.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Richards, Robert B.
Sent: Tuesday, March 6, 2018 6:17 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: FDRMOVE sample jcl
PMFJI
Just about everyone who posted on this topic had portions of their reply
somewhat in error. I might as well. :-)
If my memory serves and I do not fall into the same memory lapses as the rest
of you... circa the first release of OS/390, IBM started rebranding everything
under the DFP family to be known as DFSMSxxx. DF/DSS was no longer a product.
It was to be known as DFSMSdss. IIRC, DFHSM and DFRMM stopped being their own
products at the V2R6 level. Other former DFP products followed the same
convention: DFSMSdfp, DFSMShsm and DFSMSrmm. Integration was the reason for the
season, easier for IBM to support. DFSORT and ICKDSF remained viable with their
own branding.
As previously posted, IFAPRDxx controls whether products are enabled or not,
but I believe DFSMShsm, DFSMSdss and DFSMSrmm are shipped with every order. If
the STATE is set to ENABLED, you can use it (and start paying for it if you
weren't already). You do not DELETE those entries, you just set them to
DISABLED.
Finally ADRDSSU is a PROGRAM and not a product.
As to IDP, their suite of FDR products are very good and in some cases (but not
all) better than the IBM equivalents. Horses for courses. At the time, IBM's
integration of the DFSMS family into the OS made OS upgrades much simpler. Plus
IDP was late in delivering FDR 5.0 as the first SMS-capable release.
I'll stop now. SHIELDS UP! :-)
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of PINION, RICHARD W.
Sent: Monday, March 05, 2018 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
I'm not necessarily disagreeing with you, but DSS has a separate entry in
IFAPRDxx. I said, we're not paying for it. But we are until we can convert
application level backups to use FDRAPPL. But, if what you say is true, then
maybe applications can continue to use DSS. I'm not the person who keeps up
with the contracts and licensing.
PRODUCT OWNER('IBM CORP')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DFSMSDSS)
STATE(ENABLED)
PRODUCT OWNER('IBM CORP')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DFSMSHSM)
STATE(DISABLED)
PRODUCT OWNER('IBM CORP')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DFSMSRMM)
STATE(ENABLED)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Carmen Vitullo
Sent: Monday, March 05, 2018 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
[External Email]
HSM and RMM are other payable products/services under the DF/SMS service, but
DF/DSS 'data set services' are not payable services or product, its part of the
base or base + features.
Carmen Vitullo
- Original Message -
From: "RICHARD W. PINION"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, March 5, 2018 1:34:50 PM
Subject: Re: FDRMOVE sample jcl
DF/DSS & HSM can be deleted from the list of IBM products, and thus not be
charged for them. In our shop, we have FDR/ABR/CPK and pay for those, but we
not do pay for DF/DSS & HSM.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Carmen Vitullo
Sent: Monday, March 05, 2018 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
[External Email]
It BEEN a part of DPF for so many years, I don't order DFS services or ADRDSSU
separately or get charged for these services.
I know most folks, if they get use to using FDR they'd rather use FDR for some
functions, I know you can copy/move using ADRDSSU and once you have some good
JCL and control cards (I use ISMF to create some samples) its quite easy, but
so is FDR if you're use to it.
Carmen Vitullo
- Original Message -
From: "retired mainframer"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, March 5, 2018 1:22:12 PM
Subject: Re: FDRMOVE sample jcl
Doesn't ADRDSSU come with SMS automatically? Is it really a separately priced
product?
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Clark Morris
> Sent: Monday, March 05, 2018 10:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FDRMOVE sample jcl
>
> [Default] On 5 Mar 2018 10:11:44 -0800, in bit.listserv.ibm-main
> retired-mainfra...@q.com (retired mainframer) wrote:
>
> >Why must it be FDR? Won't ADRDSSU do it?
>
> Probably because the original poster has the Innovation products and
> doesn't have the
Re: Codepage
scott Ford wrote: I see that J R replied to you, but I am still really confused about your post. Since this is about code page, I am probably on a different [code] page ... (yes, yes, that was an intended crruel pun and I will not turn a new page, mind you... ;-D ) >I need some help on localization for codepages. The issue is we use a '~' as a >end of messages delimiter. Ouch Where is that delimiter '~' and in what code page is that? In EBCDIC or ASCII? >We have a customer wanting to use a different code page . Ebcdic codepage 285 >to ascii codepage 437 .. We place a '~' which is a x'A1' which inside the >normal Ebcdic 1140 codepage is x'7E', in 285 it is x'BC' which isn't >translating . Where do they want to use that code page? On IBM z/OS [what release?] or after a FTP (or FTPS/SFPT) on a different toy machine? >We can't use national language support yet, so we have been using a translate >table ezacic04 from CICS sockets. This table? Ok, please educate me, where are you getting that table? It looks to me you got a difficult octopus to play with... Ouch ... 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: Codepage
>From an ASCII v EBCDIC standpoint, x'00' is NUL on both sides. Why not use it >as your end of message delimiter. Of course, you haven't given the complete picture. What else is in the message stream? Is it text only? Are there any binary fields included? Control fields? Etc? > On Mar 6, 2018, at 09:54, scott Ford wrote: > > All, > > I need some help on localization for codepages. The issue is we use a '~' as > a end of messages delimiter. We have a customer wanting to use a different > code page . > Ebcdic codepage 285 to ascii codepage 437 .. We place a '~' which is a x'A1' > which inside the normal > Ebcdic 1140 codepage is x'7E', in 285 it is x'BC' which isn't translating . > We can't use national language support yet, so we have been using a translate > table ezacic04 from CICS sockets. > > > Regards, > Scott > > -- > 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: SMS/HSM QUESTION
You might also review this Technote that explains various reasons and things to look at to see what might be going on. http://www-01.ibm.com/support/docview.wss?uid=isg3T1023379 Max Smith IBM DFSMS HSM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FDRMOVE sample jcl
AH ! yep, I stand corrected.. DFSMSdfp - no wonder I'm confused Carmen Vitullo - Original Message - From: "Greg Shirey" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, March 6, 2018 9:14:26 AM Subject: Re: FDRMOVE sample jcl Actually, DFSMSdss appears as a line item on my monthly IBM invoice. I believe it is DFSMSdfp that is the base part - the "free product" as it were. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Monday, March 5, 2018 1:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FDRMOVE sample jcl HSM and RMM are other payable products/services under the DF/SMS service, but DF/DSS 'data set services' are not payable services or product, its part of the base or base + features. Carmen Vitullo -- 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: FDRMOVE sample jcl
Actually, DFSMSdss appears as a line item on my monthly IBM invoice. I believe it is DFSMSdfp that is the base part - the "free product" as it were. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Monday, March 5, 2018 1:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FDRMOVE sample jcl HSM and RMM are other payable products/services under the DF/SMS service, but DF/DSS 'data set services' are not payable services or product, its part of the base or base + features. Carmen Vitullo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Codepage
All, I need some help on localization for codepages. The issue is we use a '~' as a end of messages delimiter. We have a customer wanting to use a different code page . Ebcdic codepage 285 to ascii codepage 437 .. We place a '~' which is a x'A1' which inside the normal Ebcdic 1140 codepage is x'7E', in 285 it is x'BC' which isn't translating . We can't use national language support yet, so we have been using a translate table ezacic04 from CICS sockets. Regards, Scott -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FDRMOVE sample jcl
Ah ! the old days Bob, thanks for the walk down memory lane, I recall back in
Boeing we were using FDR exclusively, I was prod control at the time, just
before my move to SYSPROG and FDR compactors jobs were very time consuming, I
questioned the SYSPROG staff at the time, why don't we just use ADRDSSU to free
up, compact/compress volumes, you remember Paul? and so it goes, that's one
reason why FDR tools were used over IBM's ADRDSSU. the misinformation about
what tools/products we were licensed for, this way before IFAPRD and reporting
monthly to IBM.
Carmen Vitullo
- Original Message -
From: "Robert B. Richards"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, March 6, 2018 5:17:01 AM
Subject: Re: FDRMOVE sample jcl
PMFJI
Just about everyone who posted on this topic had portions of their reply
somewhat in error. I might as well. :-)
If my memory serves and I do not fall into the same memory lapses as the rest
of you... circa the first release of OS/390, IBM started rebranding everything
under the DFP family to be known as DFSMSxxx. DF/DSS was no longer a product.
It was to be known as DFSMSdss. IIRC, DFHSM and DFRMM stopped being their own
products at the V2R6 level. Other former DFP products followed the same
convention: DFSMSdfp, DFSMShsm and DFSMSrmm. Integration was the reason for the
season, easier for IBM to support. DFSORT and ICKDSF remained viable with their
own branding.
As previously posted, IFAPRDxx controls whether products are enabled or not,
but I believe DFSMShsm, DFSMSdss and DFSMSrmm are shipped with every order. If
the STATE is set to ENABLED, you can use it (and start paying for it if you
weren't already). You do not DELETE those entries, you just set them to
DISABLED.
Finally ADRDSSU is a PROGRAM and not a product.
As to IDP, their suite of FDR products are very good and in some cases (but not
all) better than the IBM equivalents. Horses for courses. At the time, IBM's
integration of the DFSMS family into the OS made OS upgrades much simpler. Plus
IDP was late in delivering FDR 5.0 as the first SMS-capable release.
I'll stop now. SHIELDS UP! :-)
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of PINION, RICHARD W.
Sent: Monday, March 05, 2018 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
I'm not necessarily disagreeing with you, but DSS has a separate entry in
IFAPRDxx. I said, we're not paying for it. But we are until we can convert
application level backups to use FDRAPPL. But, if what you say is true, then
maybe applications can continue to use DSS. I'm not the person who keeps up
with the contracts and licensing.
PRODUCT OWNER('IBM CORP')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DFSMSDSS)
STATE(ENABLED)
PRODUCT OWNER('IBM CORP')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DFSMSHSM)
STATE(DISABLED)
PRODUCT OWNER('IBM CORP')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DFSMSRMM)
STATE(ENABLED)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Carmen Vitullo
Sent: Monday, March 05, 2018 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
[External Email]
HSM and RMM are other payable products/services under the DF/SMS service, but
DF/DSS 'data set services' are not payable services or product, its part of the
base or base + features.
Carmen Vitullo
- Original Message -
From: "RICHARD W. PINION"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, March 5, 2018 1:34:50 PM
Subject: Re: FDRMOVE sample jcl
DF/DSS & HSM can be deleted from the list of IBM products, and thus not be
charged for them. In our shop, we have FDR/ABR/CPK and pay for those, but we
not do pay for DF/DSS & HSM.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Carmen Vitullo
Sent: Monday, March 05, 2018 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
[External Email]
It BEEN a part of DPF for so many years, I don't order DFS services or ADRDSSU
separately or get charged for these services.
I know most folks, if they get use to using FDR they'd rather use FDR for some
functions, I know you can copy/move using ADRDSSU and once you have some good
JCL and control cards (I use ISMF to create some samples) its quite easy, but
so is FDR if you're use to it.
Carmen Vitullo
- Original Message -
From: "retired mainframer"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, March 5, 2018 1:22:12 PM
Subject: Re: FDRMOVE sample jcl
Doesn't ADRDSSU come with SMS automatically? Is it really a separately priced
product?
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Clark Morris
> Sent: Monday, March 05, 2018 10:39 AM
> To: IBM-MAIN@LISTSERV.
Re: FDRMOVE sample jcl
PMFJI
Just about everyone who posted on this topic had portions of their reply
somewhat in error. I might as well. :-)
If my memory serves and I do not fall into the same memory lapses as the rest
of you... circa the first release of OS/390, IBM started rebranding everything
under the DFP family to be known as DFSMSxxx. DF/DSS was no longer a product.
It was to be known as DFSMSdss. IIRC, DFHSM and DFRMM stopped being their own
products at the V2R6 level. Other former DFP products followed the same
convention: DFSMSdfp, DFSMShsm and DFSMSrmm. Integration was the reason for the
season, easier for IBM to support. DFSORT and ICKDSF remained viable with their
own branding.
As previously posted, IFAPRDxx controls whether products are enabled or not,
but I believe DFSMShsm, DFSMSdss and DFSMSrmm are shipped with every order. If
the STATE is set to ENABLED, you can use it (and start paying for it if you
weren't already). You do not DELETE those entries, you just set them to
DISABLED.
Finally ADRDSSU is a PROGRAM and not a product.
As to IDP, their suite of FDR products are very good and in some cases (but not
all) better than the IBM equivalents. Horses for courses. At the time, IBM's
integration of the DFSMS family into the OS made OS upgrades much simpler. Plus
IDP was late in delivering FDR 5.0 as the first SMS-capable release.
I'll stop now. SHIELDS UP! :-)
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of PINION, RICHARD W.
Sent: Monday, March 05, 2018 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
I'm not necessarily disagreeing with you, but DSS has a separate entry in
IFAPRDxx. I said, we're not paying for it. But we are until we can convert
application level backups to use FDRAPPL. But, if what you say is true, then
maybe applications can continue to use DSS. I'm not the person who keeps up
with the contracts and licensing.
PRODUCT OWNER('IBM CORP')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DFSMSDSS)
STATE(ENABLED)
PRODUCT OWNER('IBM CORP')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DFSMSHSM)
STATE(DISABLED)
PRODUCT OWNER('IBM CORP')
NAME('z/OS')
ID(5650-ZOS)
VERSION(*) RELEASE(*) MOD(*)
FEATURENAME(DFSMSRMM)
STATE(ENABLED)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Carmen Vitullo
Sent: Monday, March 05, 2018 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
[External Email]
HSM and RMM are other payable products/services under the DF/SMS service, but
DF/DSS 'data set services' are not payable services or product, its part of the
base or base + features.
Carmen Vitullo
- Original Message -
From: "RICHARD W. PINION"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, March 5, 2018 1:34:50 PM
Subject: Re: FDRMOVE sample jcl
DF/DSS & HSM can be deleted from the list of IBM products, and thus not be
charged for them. In our shop, we have FDR/ABR/CPK and pay for those, but we
not do pay for DF/DSS & HSM.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Carmen Vitullo
Sent: Monday, March 05, 2018 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl
[External Email]
It BEEN a part of DPF for so many years, I don't order DFS services or ADRDSSU
separately or get charged for these services.
I know most folks, if they get use to using FDR they'd rather use FDR for some
functions, I know you can copy/move using ADRDSSU and once you have some good
JCL and control cards (I use ISMF to create some samples) its quite easy, but
so is FDR if you're use to it.
Carmen Vitullo
- Original Message -
From: "retired mainframer"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, March 5, 2018 1:22:12 PM
Subject: Re: FDRMOVE sample jcl
Doesn't ADRDSSU come with SMS automatically? Is it really a separately priced
product?
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Clark Morris
> Sent: Monday, March 05, 2018 10:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FDRMOVE sample jcl
>
> [Default] On 5 Mar 2018 10:11:44 -0800, in bit.listserv.ibm-main
> retired-mainfra...@q.com (retired mainframer) wrote:
>
> >Why must it be FDR? Won't ADRDSSU do it?
>
> Probably because the original poster has the Innovation products and
> doesn't have the DSS/HSM products.
-
Re: Tape to tape copy jcl
Venkat, I'm not sure Gil's REXX is going to help you. Can you confirm a few things for me? You don't have any tape management system, and you have @1000 tapes? If there is no software to manage them, how do you do it? How do you know what's on each tape, when it can be overwritten etc etc? You only write to tape using IEBGENER / IEBCOPY? You don't use anything to migrate "old" data to tape? You don't use a product like DFDSS or FDR to do full volume dumps? (You say you use IEBCOPY IEBGENER to do "volume copies" - I'm not sure I understand that) Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Actually www.ibm.com/us-en was Re: Connor Krukosky is on the Main Webpage at www.ibm.com
You know I've been pretty quiet on this list since I started at IBM and started working on the z14 and the newer and more exciting things that I am unfortunately not able to discuss ;) But I figured I would remind everyone here that it was all thanks to this list all of this happened. From the warm welcoming of the people on this list to the support I received is the primary reason I was able to continue to follow my passion! I thank you all for the support you share here on this list and sister lists like IBM-VM and other such Mainframe related forums and lists. Its really all of you that make this platform great, IBM and now I help supply you the hardware and software, but its thanks to you all that people like me can get their start and ask the questions IBM may charge for, or might be buried in manuals that some don't have the patience to dig through ;) Continue being awesome and helpful as you all have been and I will continue my passion at IBM and in my hobbies as I hope everyone is able to do just the same as I have. Well maybe not exactly the same... But seriously, if you want to do something, go for it!! People ask me if they should buy a mainframe, I say go for it if you want to! Thanks everyone, I don't forget about this list, I just get caught up in my projects ;) -Connor Krukosky On 3/5/2018 4:01 PM, Clark Morris wrote: [Default] On 5 Mar 2018 12:14:50 -0800, in bit.listserv.ibm-main charl...@mcn.org (Charles Mills) wrote: I can select the ca-en page from the US. A corollary might be that you could select us-en from Canada. I just overtyped the URL. That worked. Clark Morris Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris Sent: Monday, March 5, 2018 12:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Connor Krukosky is on the Main Webpage at www.ibm.com [Default] On 5 Mar 2018 11:46:12 -0800, in bit.listserv.ibm-main jesse1.robin...@sce.com (Jesse 1 Robinson) wrote: Marvel seems always to be on the lookout for a new superhero character... I don't see it in Canada where IBM forces me to the ca-en page. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
