Re: Serverpac installs January 2022 and beyond - Requests
I realized as much. However, that's one way for IBM to build a bridge. zSMB or something. Instead of leaving no option but to get out-of-support older machines (and h/w support from other companies), or getting more MSUs and such... IBM could instead sell software-only small machine. Comparing Mac Pro to a full-on z15, IBM could offer a Mac mini or Macbook Air. Business class model will be more like MacBook Pro or something. - KB ‐‐‐ Original Message ‐‐‐ On Sunday, July 25th, 2021 at 10:24 AM, Brian Westerman wrote: > Unfortunately, you can't run a production system on a zPDT, it's not allowed > under the agreement with IBM. > > On Sat, 24 Jul 2021 05:41:56 +, kekronbekron kekronbek...@protonmail.com > wrote: > > > And therein begins a new line where some company offers services to move > > small machine workloads to zPDT. > > > > Or whatever... > > > > - KB > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Saturday, July 24th, 2021 at 9:51 AM, Brian Westerman > > brian_wester...@syzygyinc.com wrote: > > > > > Did you think to have even ONE of those early sites be one with a small > > > processor (single CPU) like a low end single CPU z/13, z14 or z15? Most > > > likely you didn't and that's very sad. A good percentage of "new" clients > > > that IBM has added over the past 5 to 8 years are in that boat and IBM > > > has decided to set sail without them. > > > > > > I have no doubt that the early customers represented vast swaths of > > > geographies and industries, but how low did you guys dip to test with a > > > "small" site. The ones IBM called strategic so that they would not go to > > > Open Systems and instead go with a small box and z/OS? > > > > > > It's very disappointing. Not all of the people IBM is ignoring have > > > access to large and small boxes like I do, if you have a small box and > > > want to upgrade after January to 2.5 from say 2.3, they will not be able > > > to do it without beefing up their machine or coming to someone like us to > > > do it for them. I'm not complaining about the business that IBM is > > > pushing my way, but I think it's sad that IBM appears to care very little > > > about the damage (via frustration) they are about to do. Some will buy an > > > upgraded box, but many will simply drop their mainframe path in favor of > > > some other direction (away from z/OS). > > > > > > Brian > > > > > > On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE mwa...@us.ibm.com wrote: > > > > > > > Brian, > > > > > > > > > > Some of the problem here is that you are telling me what "will" be > > > > > > there, but I don't have anything that actually shows that or even > > > > > > implies it for z/OSMF for z/OS. I don't even have the workflows to > > > > > > verify anything. > > > > > > > > For the z/OS Workflows that you haven't seen yet, they are Workflow > > > > steps that are submitting the same JCL jobs that you used to submit > > > > through the ISPF interface and should be familiar with today. Meaning, > > > > instead of using an ISPF panel to submit the job, you will now submit > > > > those same jobs from the z/OSMF Workflow interface. That is the > > > > difference. The jobs remain the same, in probably 99.99% of the cases. > > > > They are being converted from ISPF JCL skeletons (SCPPSENU) to z/OSMF > > > > Workflow JCL templates (XML). So yes, you haven't seen them in their > > > > XML format, but you certainly have seen them when they were JCL > > > > skeletons. And remember, every single Workflow step JCL that is > > > > submitted is able to be edited from z/OSMF, just like it was with the > > > > CustomPac dialog. > > > > > > > > Might there be a conversion error to XML? Yes, of course that is > > > > possible. But that is why we have my second comment below... > > > > > > > > > > People won't have much time between Late September and January to > > > > > > discover and correct all of the bugs. > > > > > > > > For each z/OS new release, and V2.5 more than ever, there are early > > > > customer programs. The release level early program for z/OS V2.5 has > > > > its main focus on the installation of and upgrade to z/OS V2.5. We > > > > understood that the installation process would be different and wanted > > > > as much exposure, testing, and validation in customer environments > > > > before it GAs. We have early customers that represent many different > > > > industries and geographies. Each of these customers has installed with > > > > a z/OS V2.5 z/OSMF ServerPac. Not a single one of them used the old > > > > ISPF ServerPac. > > > > > > > > -Marna WALLE > > > > > > > > z/OS System Install and Upgrade > > > > > > > > IBM Poughkeepsie > > > > > > > > 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
Re: Excessive resource use was Re: Serverpac installs January 2022 and beyond - Requests
Not really, the smaller the shop, the less programmers they have performing compiles, even if it takes 4 to 5 times as long to compile LE COBOL compared to something like COBOL-II, there are not enough of them to really matter. A large shop wouldn't see that same problem, because while the compile times have gotten higher, the normally have the capacity to handle it, or at least handle it better. Brian On Sat, 24 Jul 2021 12:19:58 -0300, Clark Morris wrote: >[Default] On 23 Jul 2021 21:21:19 -0700, in bit.listserv.ibm-main >brian_wester...@syzygyinc.com (Brian Westerman) wrote: > >>Did you think to have even ONE of those early sites be one with a small >>processor (single CPU) like a low end single CPU z/13, z14 or z15? Most >>likely you didn't and that's very sad. A good percentage of "new" clients >>that IBM has added over the past 5 to 8 years are in that boat and IBM has >>decided to set sail without them. > >In addition to the resource use by z/OSMF, at the last SHARE Tom Ross >reported that the current COBOL compile takes significantly more >resources. Since IBM is moving to common compiler backends, has this >become a problem for small shops? > >Clark Morris >> >>I have no doubt that the early customers represented vast swaths of >>geographies and industries, but how low did you guys dip to test with a >>"small" site. The ones IBM called strategic so that they would not go to >>Open Systems and instead go with a small box and z/OS? >> >>It's very disappointing. Not all of the people IBM is ignoring have access >>to large and small boxes like I do, if you have a small box and want to >>upgrade after January to 2.5 from say 2.3, they will not be able to do it >>without beefing up their machine or coming to someone like us to do it for >>them. I'm not complaining about the business that IBM is pushing my way, but >>I think it's sad that IBM appears to care very little about the damage (via >>frustration) they are about to do. Some will buy an upgraded box, but many >>will simply drop their mainframe path in favor of some other direction (away >>from z/OS). >> >>Brian >> >> >>On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE wrote: >> >>>Brian, > Some of the problem here is that you are telling me what "will" be there, > but I don't have anything that actually shows that or even implies it for > z/OSMF for z/OS. I don't even have the workflows to verify anything. >>> >>>For the z/OS Workflows that you haven't seen yet, they are Workflow steps >>>that are submitting the same JCL jobs that you used to submit through the >>>ISPF interface and should be familiar with today. Meaning, instead of using >>>an ISPF panel to submit the job, you will now submit those same jobs from >>>the z/OSMF Workflow interface. That is the difference. The jobs remain the >>>same, in probably 99.99% of the cases. They are being converted from ISPF >>>JCL skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, >>>you haven't seen them in their XML format, but you certainly have seen them >>>when they were JCL skeletons. And remember, every single Workflow step JCL >>>that is submitted is able to be edited from z/OSMF, just like it was with >>>the CustomPac dialog. >>> >>>Might there be a conversion error to XML? Yes, of course that is possible. >>>But that is why we have my second comment below... >>> >>> > People won't have much time between Late September and January to > discover and correct all of the bugs. >>> >>>For each z/OS new release, and V2.5 more than ever, there are early customer >>>programs. The release level early program for z/OS V2.5 has its main focus >>>on the installation of and upgrade to z/OS V2.5. We understood that the >>>installation process would be different and wanted as much exposure, >>>testing, and validation in customer environments before it GAs. We have >>>early customers that represent many different industries and geographies. >>>Each of these customers has installed with a z/OS V2.5 z/OSMF ServerPac. >>>Not a single one of them used the old ISPF ServerPac. >>> >>>-Marna WALLE >>>z/OS System Install and Upgrade >>>IBM Poughkeepsie >>> >>>-- >>>For IBM-MAIN subscribe / signoff / archive access instructions, >>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >>-- >>For IBM-MAIN subscribe / signoff / archive access instructions, >>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access
Re: Serverpac installs January 2022 and beyond - Requests
Unfortunately, you can't run a production system on a zPDT, it's not allowed under the agreement with IBM. On Sat, 24 Jul 2021 05:41:56 +, kekronbekron wrote: >And therein begins a new line where some company offers services to move small >machine workloads to zPDT. >Or whatever... > >- KB > >‐‐‐ Original Message ‐‐‐ > >On Saturday, July 24th, 2021 at 9:51 AM, Brian Westerman > wrote: > >> Did you think to have even ONE of those early sites be one with a small >> processor (single CPU) like a low end single CPU z/13, z14 or z15? Most >> likely you didn't and that's very sad. A good percentage of "new" clients >> that IBM has added over the past 5 to 8 years are in that boat and IBM has >> decided to set sail without them. >> >> I have no doubt that the early customers represented vast swaths of >> geographies and industries, but how low did you guys dip to test with a >> "small" site. The ones IBM called strategic so that they would not go to >> Open Systems and instead go with a small box and z/OS? >> >> It's very disappointing. Not all of the people IBM is ignoring have access >> to large and small boxes like I do, if you have a small box and want to >> upgrade after January to 2.5 from say 2.3, they will not be able to do it >> without beefing up their machine or coming to someone like us to do it for >> them. I'm not complaining about the business that IBM is pushing my way, but >> I think it's sad that IBM appears to care very little about the damage (via >> frustration) they are about to do. Some will buy an upgraded box, but many >> will simply drop their mainframe path in favor of some other direction (away >> from z/OS). >> >> Brian >> >> On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE mwa...@us.ibm.com wrote: >> >> > Brian, >> > >> > > > Some of the problem here is that you are telling me what "will" be >> > > > there, but I don't have anything that actually shows that or even >> > > > implies it for z/OSMF for z/OS. I don't even have the workflows to >> > > > verify anything. >> > >> > For the z/OS Workflows that you haven't seen yet, they are Workflow steps >> > that are submitting the same JCL jobs that you used to submit through the >> > ISPF interface and should be familiar with today. Meaning, instead of >> > using an ISPF panel to submit the job, you will now submit those same jobs >> > from the z/OSMF Workflow interface. That is the difference. The jobs >> > remain the same, in probably 99.99% of the cases. They are being converted >> > from ISPF JCL skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). >> > So yes, you haven't seen them in their XML format, but you certainly have >> > seen them when they were JCL skeletons. And remember, every single >> > Workflow step JCL that is submitted is able to be edited from z/OSMF, just >> > like it was with the CustomPac dialog. >> > >> > Might there be a conversion error to XML? Yes, of course that is possible. >> > But that is why we have my second comment below... >> > >> > > > People won't have much time between Late September and January to >> > > > discover and correct all of the bugs. >> > >> > For each z/OS new release, and V2.5 more than ever, there are early >> > customer programs. The release level early program for z/OS V2.5 has its >> > main focus on the installation of and upgrade to z/OS V2.5. We understood >> > that the installation process would be different and wanted as much >> > exposure, testing, and validation in customer environments before it GAs. >> > We have early customers that represent many different industries and >> > geographies. Each of these customers has installed with a z/OS V2.5 z/OSMF >> > ServerPac. Not a single one of them used the old ISPF ServerPac. >> > >> > -Marna WALLE >> > >> > z/OS System Install and Upgrade >> > >> > IBM Poughkeepsie >> > >> > For IBM-MAIN subscribe / signoff / archive access instructions, >> > >> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> For IBM-MAIN subscribe / signoff / archive access instructions, >> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MF talent wanted
Listers, Would like to seek 1 (ONE) MF system engineer who can perform classical z ,such as z/OS , CICS, DB2/z and capable skills on z/Linux solutions. Mandarin speaking, staying in Taiwan, perform client facing projects. Welcome and thanks recommendation. 從我的iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mixing C/C++ with LE-conforming IBM HLASM
On Sat, 24 Jul 2021 12:01:09 -0500, Kirk Wolf wrote: >Sorry for joining this thread late. > >You are correct Larry - the z/OS C library has very little help for PDS >processing. I wrote an RFE in 2015, but I don't expect to want it >anymore if/when IBM responds :-) >https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=80811 > >We recently released two new shell command utilities in Co:Z which have >all sorts of options for loading/unloading PDS/PDSEs to/from zFS files. > Nice. Why is the "//" required? It might be presumed. But it leaves syntactic leeway for future extension to UNIX<->UNIX copy. >https://www.dovetail.com/docs/zos-utilities/dsp-ref_getpds.html There's no "-l record" option. That format, provided by allocation is seldom used, but needed to support files containing a line-separator as data. (Is this "l4", not mentioned in the list of option values?) >https://dovetail.com/docs/zos-utilities/dsp-ref_putpds.html > is -i l4 or FILE DATA(RECORD) supported? If the -l or -s option is omitted, are the tag values of the source files individually respected? (pax does some of this, however poorly.) JCL respects the FILEDATA of a tagged source file (undocumented) How are UNICODE conversion errors treated/reported? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mixing C/C++ with LE-conforming IBM HLASM
Sorry for joining this thread late. You are correct Larry - the z/OS C library has very little help for PDS processing. I wrote an RFE in 2015, but I don't expect to want it anymore if/when IBM responds :-) https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=80811 We recently released two new shell command utilities in Co:Z which have all sorts of options for loading/unloading PDS/PDSEs to/from zFS files. https://www.dovetail.com/docs/zos-utilities/dsp-ref_getpds.html https://dovetail.com/docs/zos-utilities/dsp-ref_putpds.html The code is 98% C++, with bpam/bsam assembler routines. Our C++ is 31-bit LE with XPLINK (IMO the only rational linkage for C++ at scale). Our assembler code is quite small and uses XPLINK linkage macros (EDCXPRLG, EDCXEPLG) and also the XPLINK stack local data. This is *so* much nicer than the old way of writing reentrant code. All of the BSAM fancies (DECB/buffer queue, record blocking, etc) is done in C++. Only one DCB (BPAM/BSAM). The performance of loading/unloading a large PDS/PDSE is great - like two orders of magnitude faster than /bin/cp which opens the dataset for each and every member :-) We also support ISPF-style ENQs with DISP=SHR, which is really handy for many use cases, like devops. Kirk Wolf Dovetailed Technologies http://dovetail.com On 7/17/21 6:25 PM, Larry Slaten wrote: Thanks to everyone for their input. Since I was already using C/C++ I/0 functions to access a card file I thought that it would be simple enough to setup the DD:SYSLIB and that it would actually point me to a DCB address that I could use in my BLDL and LOAD macro(s). I ended up defining the DCB in my assembler program and did all of the right stuff to maintain re-entrant code. It would have been nice if the DCB address would have been easily accessible. -- 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
Excessive resource use was Re: Serverpac installs January 2022 and beyond - Requests
[Default] On 23 Jul 2021 21:21:19 -0700, in bit.listserv.ibm-main brian_wester...@syzygyinc.com (Brian Westerman) wrote: >Did you think to have even ONE of those early sites be one with a small >processor (single CPU) like a low end single CPU z/13, z14 or z15? Most >likely you didn't and that's very sad. A good percentage of "new" clients >that IBM has added over the past 5 to 8 years are in that boat and IBM has >decided to set sail without them. In addition to the resource use by z/OSMF, at the last SHARE Tom Ross reported that the current COBOL compile takes significantly more resources. Since IBM is moving to common compiler backends, has this become a problem for small shops? Clark Morris > >I have no doubt that the early customers represented vast swaths of >geographies and industries, but how low did you guys dip to test with a >"small" site. The ones IBM called strategic so that they would not go to Open >Systems and instead go with a small box and z/OS? > >It's very disappointing. Not all of the people IBM is ignoring have access to >large and small boxes like I do, if you have a small box and want to upgrade >after January to 2.5 from say 2.3, they will not be able to do it without >beefing up their machine or coming to someone like us to do it for them. I'm >not complaining about the business that IBM is pushing my way, but I think >it's sad that IBM appears to care very little about the damage (via >frustration) they are about to do. Some will buy an upgraded box, but many >will simply drop their mainframe path in favor of some other direction (away >from z/OS). > >Brian > > >On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE wrote: > >>Brian, Some of the problem here is that you are telling me what "will" be there, but I don't have anything that actually shows that or even implies it for z/OSMF for z/OS. I don't even have the workflows to verify anything. >> >>For the z/OS Workflows that you haven't seen yet, they are Workflow steps >>that are submitting the same JCL jobs that you used to submit through the >>ISPF interface and should be familiar with today. Meaning, instead of using >>an ISPF panel to submit the job, you will now submit those same jobs from the >>z/OSMF Workflow interface. That is the difference. The jobs remain the same, >>in probably 99.99% of the cases. They are being converted from ISPF JCL >>skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, you >>haven't seen them in their XML format, but you certainly have seen them when >>they were JCL skeletons. And remember, every single Workflow step JCL that >>is submitted is able to be edited from z/OSMF, just like it was with the >>CustomPac dialog. >> >>Might there be a conversion error to XML? Yes, of course that is possible. >>But that is why we have my second comment below... >> >> People won't have much time between Late September and January to discover and correct all of the bugs. >> >>For each z/OS new release, and V2.5 more than ever, there are early customer >>programs. The release level early program for z/OS V2.5 has its main focus >>on the installation of and upgrade to z/OS V2.5. We understood that the >>installation process would be different and wanted as much exposure, testing, >>and validation in customer environments before it GAs. We have early >>customers that represent many different industries and geographies. Each of >>these customers has installed with a z/OS V2.5 z/OSMF ServerPac. Not a >>single one of them used the old ISPF ServerPac. >> >>-Marna WALLE >>z/OS System Install and Upgrade >>IBM Poughkeepsie >> >>-- >>For IBM-MAIN subscribe / signoff / archive access instructions, >>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GDPS Manuals Link
To be fair, they're really not that hard to get a hold of. We haven't used GDPC/XRC since 2016; they still send me the newsletter and the FTP site password every time they change it. Both the user ID and the password in the same unencrypted email. They don't seem to be too concerned about the general public accessing the doc., etc. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Saturday, July 24, 2021 9:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GDPS Manuals Link [External Email. Exercise caution when clicking links or opening attachments.] W dniu 22.07.2021 o 22:46, fred glenlake pisze: > Hi List, > > I am unsuccessfully trying to locate the hiding spot of the GDPS Manuals for > V4R1 so I can download a few. If anyone can share the link of where I could > download them please. GDPS is closed. Manuals are not available to anyone. Even list of manuals. Even GDPS courses require GDPS license as a prerequisite. Funny: the instructor need not to be "licensed" or currently working with GDPS. The only open source of knowledge is Redbook. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GDPS Manuals Link
W dniu 22.07.2021 o 22:46, fred glenlake pisze: Hi List, I am unsuccessfully trying to locate the hiding spot of the GDPS Manuals for V4R1 so I can download a few. If anyone can share the link of where I could download them please. GDPS is closed. Manuals are not available to anyone. Even list of manuals. Even GDPS courses require GDPS license as a prerequisite. Funny: the instructor need not to be "licensed" or currently working with GDPS. The only open source of knowledge is Redbook. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
There are many ways to skin a cat. You can rely on industry standards like certificates and CA's. You can also use your own methods. You can use both. Yes, double security. What I could do: 1. Establish some secure file transfer. It can be FTPS, sftp, commercial MFT applications like Sterling Connect, MQ MFT, etc. 2. Just to sleep better I would also encipher the dataset before it is sent. Again, it can be done using commercial tools like Encryption Facility or Megacryption or other. Of course it is feasible to encrypt dataset using your own tools. Why two methods? Well, both are safe ...until someone made a mistake. Assuming some separation of duties it would be more idiotproof and proof of malicious insider. -- Radoslaw Skorupka Lodz, Poland W dniu 22.07.2021 o 16:07, Colin Paice pisze: I was wondering the best way customers send sensitive data between z/OS images. I was thinking about exporting one's private certificates. 1. I can create a dataset of the private certificates on system 1 and have it encrypted. I can send it to the other system. How can I decrypt it on the remote system as it needs shared certificates? It seems a chicken and egg problem 2. I can put a password on the file through JCL and use FTPS to send it. This could easily be broken This is hypothetical, but I would be interested in how to do it. Colin Paice -- 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
