Re: IBM 3270 Font Available in Various Formats
Tx Timothy. Will give it a try. ITschak On Wed, Jan 22, 2020 at 9:27 AM Timothy Sipples wrote: > ITschak wrote: > >mac brew doesn't recognize this package -( > > OK, but you're not required to build the "IBM 3270" font from source > specifically on macOS. There's also a download link to the prebuilt font > files (.ttf, .otf), and you should find they're suitable for immediate use > on macOS. Just place the .otf files in your Library/Fonts folder. > > > > Timothy Sipples > IT Architect Executive, Digital Asset & Other Industry Solutions, IBM Z & > LinuxONE > > > > 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 > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM 3270 Font Available in Various Formats
ITschak wrote: >mac brew doesn't recognize this package -( OK, but you're not required to build the "IBM 3270" font from source specifically on macOS. There's also a download link to the prebuilt font files (.ttf, .otf), and you should find they're suitable for immediate use on macOS. Just place the .otf files in your Library/Fonts folder. Timothy Sipples IT Architect Executive, Digital Asset & Other Industry Solutions, IBM Z & LinuxONE 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: IBM AOAR O44855
there are so many other alternatives to ddos by wide user revoke. even if you do not install the ptf, the attacker can use the pcomm (or whatsoever is in use) API to perform same type of attack. ITschak On Tue, Jan 21, 2020 at 6:32 PM Seymour J Metz wrote: > That opens the way to a denial of service attack; someone can write a > script to cause revocation of a long list of userids. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Barbara Nitz > Sent: Tuesday, January 21, 2020 2:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IBM AOAR O44855 > > >Is anyone using this feature > https://www-01.ibm.com/support/docview.wss?uid=isg1OA44855 > > I implemented TSO PrePrompt when I was RACF Admin. If someone is > attempting to hack into the mainframe using userid/password, I didn't want > them to know if their userid was wrong or their password. > After x invalid combinations (x is whatever your amount of allowed invalid > passwords is before revoking you) the userid gets revoked, as before. > > It threw off the session manager we used to use back then, and it threw > off a screenscraper that the compliance department uses > (screenscraper=shudder). Both got around it. > > Barbara > > -- > 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 > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3592-E07
We are using Ken's Visara VTL solution and are very happy with it. Tony Thigpen Ken Bloom wrote on 1/21/20 3:10 PM: Hi Dean VTS solutions are not as expensive as you think they are depending on the amount of storage and number of channels required. Besides the vastly improved performance of a VTS over std tape, you get the additional reduction in footprint and power requirements which have the secondary effect of reducing your DR costs. If you would like to consider this option, please contact me off line. Regards Ken Kenneth A. Bloom CEO Avenir Technologies Inc /d/b/a Visara International 203-984-2235 bl...@visara.com www.visara.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nai, Dean Sent: Tuesday, January 21, 2020 3:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 3592-E07 We have a 3592-E07 and our leasing company is telling us the following. Anyone have any thoughts? We really don’t have the funding for a mirrored VTS and if it’s not mirrored then we lose our DR plan. From leasing company. The first item to be withdrawn from service will be the 3592-C07 at the end of 2020. The C07 is the controller for the tape drives and is required for z/OS or z/VM to communicate with the 3592-E07 drives. IBM has no direct attach tape products for z/OS, z/VM or zVSE. The best option is to go with a VTS and locate a 2nd VTS at your DR site with replication between the two sites. There is also the option to have an IBM VTS with access to tape drives in a 3584 and then send those tapes offsite. To be able to use those tapes for DR you would need another IBM VTS at you DR location. Dean Nai -- 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: 3592-E07
Neal, We use this "grid" type VTL solution here at A&M - one locally in Texas, and the other at our DR co-lo in MD. Work well, as long as your internet connection is sound. Regards, James Lund | Chief Systems Engineer Mainframe and Enterprise Backup Service | Division of Information Technology Texas A&M University 3363 TAMU | College Station, TX 77843-3363 ph: 979.845.8410 | fax: 979.845.2074 | james-l...@tamu.edu - - - - - - - - - - - - - - - - - - - - - - - - IT.tamu.edu -Original Message- From: IBM Mainframe Discussion List On Behalf Of Nai, Dean Sent: Tuesday, January 21, 2020 2:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] 3592-E07 We have a 3592-E07 and our leasing company is telling us the following. Anyone have any thoughts? We really don’t have the funding for a mirrored VTS and if it’s not mirrored then we lose our DR plan. From leasing company. The first item to be withdrawn from service will be the 3592-C07 at the end of 2020. The C07 is the controller for the tape drives and is required for z/OS or z/VM to communicate with the 3592-E07 drives. IBM has no direct attach tape products for z/OS, z/VM or zVSE. The best option is to go with a VTS and locate a 2nd VTS at your DR site with replication between the two sites. There is also the option to have an IBM VTS with access to tape drives in a 3584 and then send those tapes offsite. To be able to use those tapes for DR you would need another IBM VTS at you DR location. Dean Nai > -- 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: 3592-E07
Hi Dean VTS solutions are not as expensive as you think they are depending on the amount of storage and number of channels required. Besides the vastly improved performance of a VTS over std tape, you get the additional reduction in footprint and power requirements which have the secondary effect of reducing your DR costs. If you would like to consider this option, please contact me off line. Regards Ken Kenneth A. Bloom CEO Avenir Technologies Inc /d/b/a Visara International 203-984-2235 bl...@visara.com www.visara.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nai, Dean Sent: Tuesday, January 21, 2020 3:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 3592-E07 We have a 3592-E07 and our leasing company is telling us the following. Anyone have any thoughts? We really don’t have the funding for a mirrored VTS and if it’s not mirrored then we lose our DR plan. From leasing company. The first item to be withdrawn from service will be the 3592-C07 at the end of 2020. The C07 is the controller for the tape drives and is required for z/OS or z/VM to communicate with the 3592-E07 drives. IBM has no direct attach tape products for z/OS, z/VM or zVSE. The best option is to go with a VTS and locate a 2nd VTS at your DR site with replication between the two sites. There is also the option to have an IBM VTS with access to tape drives in a 3584 and then send those tapes offsite. To be able to use those tapes for DR you would need another IBM VTS at you DR location. Dean Nai > -- 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
3592-E07
We have a 3592-E07 and our leasing company is telling us the following. Anyone have any thoughts? We really don’t have the funding for a mirrored VTS and if it’s not mirrored then we lose our DR plan. From leasing company. The first item to be withdrawn from service will be the 3592-C07 at the end of 2020. The C07 is the controller for the tape drives and is required for z/OS or z/VM to communicate with the 3592-E07 drives. IBM has no direct attach tape products for z/OS, z/VM or zVSE. The best option is to go with a VTS and locate a 2nd VTS at your DR site with replication between the two sites. There is also the option to have an IBM VTS with access to tape drives in a 3584 and then send those tapes offsite. To be able to use those tapes for DR you would need another IBM VTS at you DR location. Dean Nai > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM AOAR O44855
On Tue, 21 Jan 2020 10:40:07 -0800, Charles Mills wrote: >I do not disagree. The decision to revoke is in the customer's hands. Before >this APAR, the option to only say that the combination was invalid did not >exist. So the APAR is 100% a good thing. > (some topic drift) I suspect (novice) that C programmers rely on ioctl(?) fcntl(?) to suppress echoing keystrokes during password entry. Long ago I tried a test. So suppressing echo works as expected in a ssh session to z/OS UNIX. But in a 3270 OMVS session the password is visible during entry regardless. I went to SR. IBM took no action. I believe this is the motivation for IBM's partially prohibiting ssh and sftp from 3270 OMVS sessions. FTP has never endured such a restriction. I've discovered that /bin/script cleanses the 3270-ness of an OMVS session and I can then use ssh and sftp but the password is displayed. The password does not appear in the typescript output file. (Don't tell IBM.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM AOAR O44855
On Tue, 21 Jan 2020 10:40:07 -0800, Charles Mills wrote: >I do not disagree. The decision to revoke is in the customer's hands. Before >this APAR, the option to only say that the combination was invalid did not >exist. So the APAR is 100% a good thing. > If it's desirable to prevent disclosure of user IDs, there should be an option to mask the user ID during entry, even as is done for the password. I have used a system where the only application supported was TSO so VTAM(?) was configured to display the full-screen login immediately on connection, before any user information is entered. How does that play with O44855? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH and IARV64
Chris I remember your post so much so I am now aware making sure the SDWALSED Is set right on a retry if the abend was whitin a BAKR > On Jan 21, 2020, at 2:12 PM, Christopher Y. Blaicher > wrote: > > A note on creating a recovery routine (ESTAE or ESTAEX). If you create an > ESTAE in a subroutine and use BAKR/PR to get to and return from that > subroutine, the ESTAE gets deleted by PR. Another programmer wrote an > INITIALIZE subroutine where the ESTAE was created, only I was never going to > the ESTAE and I couldn't figure out why for the longest time. > > Chris Blaicher > Technical Architect > Syncsort, Inc. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Joseph Reichman > Sent: Tuesday, January 21, 2020 2:05 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ATTACH and IARV64 > > [ External - This message has originated from an External Source. Please use > proper judgment and caution when opening attachments, clicking links, or > responding to this email ] > > So if task B frees tasks A storage and it’s not shared I would get a B37 type > error ? > > A related question if I load a program in task A task B can use it access and > invoke it And even use it as a ( recovery routine just trying to figure out > why recovery routine didn’t work ) > > Thanks > > > > > >> On Jan 21, 2020, at 1:58 PM, Binyamin Dissen >> wrote: >> >> I believe that you have a misunderstanding of what "shared subpools" are. >> >> Any task in an address space has addressability to private storage of >> any other task. Nothing special is required for this. >> >> A "shared subpool" is one where those sharing the subpool can directly >> allocate and free the storage and the storage lives until the last >> user of the subpool (which would be the initial parent task doing the ATTACH >> SHSP) ends. >> The storage is not freed when the subtasks end. >> >> There is no real concept of "subpools" in 64bit as the area is not >> suballocated by the system. >> >> >> >> On Tue, 21 Jan 2020 10:19:17 -0500 Joseph Reichman >> >> wrote: >> >> :>Under to 2GB bar the attach has a parameter SHSPV parameter to share >> storage :>or subpool with another task in the same address space :> :> >> :> :>Above the 2GB I am assuming I would need to do a GETSHARED >> request ? >> >> -- >> 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 > > -- > 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: ATTACH and IARV64
A note on creating a recovery routine (ESTAE or ESTAEX). If you create an ESTAE in a subroutine and use BAKR/PR to get to and return from that subroutine, the ESTAE gets deleted by PR. Another programmer wrote an INITIALIZE subroutine where the ESTAE was created, only I was never going to the ESTAE and I couldn't figure out why for the longest time. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joseph Reichman Sent: Tuesday, January 21, 2020 2:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH and IARV64 [ External - This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email ] So if task B frees tasks A storage and it’s not shared I would get a B37 type error ? A related question if I load a program in task A task B can use it access and invoke it And even use it as a ( recovery routine just trying to figure out why recovery routine didn’t work ) Thanks > On Jan 21, 2020, at 1:58 PM, Binyamin Dissen > wrote: > > I believe that you have a misunderstanding of what "shared subpools" are. > > Any task in an address space has addressability to private storage of > any other task. Nothing special is required for this. > > A "shared subpool" is one where those sharing the subpool can directly > allocate and free the storage and the storage lives until the last > user of the subpool (which would be the initial parent task doing the ATTACH > SHSP) ends. > The storage is not freed when the subtasks end. > > There is no real concept of "subpools" in 64bit as the area is not > suballocated by the system. > > > > On Tue, 21 Jan 2020 10:19:17 -0500 Joseph Reichman > > wrote: > > :>Under to 2GB bar the attach has a parameter SHSPV parameter to share > storage :>or subpool with another task in the same address space :> :> > :> :>Above the 2GB I am assuming I would need to do a GETSHARED > request ? > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH and IARV64
So if task B frees tasks A storage and it’s not shared I would get a B37 type error ? A related question if I load a program in task A task B can use it access and invoke it And even use it as a ( recovery routine just trying to figure out why recovery routine didn’t work ) Thanks > On Jan 21, 2020, at 1:58 PM, Binyamin Dissen > wrote: > > I believe that you have a misunderstanding of what "shared subpools" are. > > Any task in an address space has addressability to private storage of any > other task. Nothing special is required for this. > > A "shared subpool" is one where those sharing the subpool can directly > allocate and free the storage and the storage lives until the last user of the > subpool (which would be the initial parent task doing the ATTACH SHSP) ends. > The storage is not freed when the subtasks end. > > There is no real concept of "subpools" in 64bit as the area is not > suballocated by the system. > > > > On Tue, 21 Jan 2020 10:19:17 -0500 Joseph Reichman > wrote: > > :>Under to 2GB bar the attach has a parameter SHSPV parameter to share storage > :>or subpool with another task in the same address space > :> > :> > :> > :>Above the 2GB I am assuming I would need to do a GETSHARED request ? > > -- > 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: ATTACH and IARV64
I believe that you have a misunderstanding of what "shared subpools" are. Any task in an address space has addressability to private storage of any other task. Nothing special is required for this. A "shared subpool" is one where those sharing the subpool can directly allocate and free the storage and the storage lives until the last user of the subpool (which would be the initial parent task doing the ATTACH SHSP) ends. The storage is not freed when the subtasks end. There is no real concept of "subpools" in 64bit as the area is not suballocated by the system. On Tue, 21 Jan 2020 10:19:17 -0500 Joseph Reichman wrote: :>Under to 2GB bar the attach has a parameter SHSPV parameter to share storage :>or subpool with another task in the same address space :> :> :> :>Above the 2GB I am assuming I would need to do a GETSHARED request ? -- 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: IBM AOAR O44855
I do not disagree. The decision to revoke is in the customer's hands. Before this APAR, the option to only say that the combination was invalid did not exist. So the APAR is 100% a good thing. Yes, I would certainly agree that a delay option might be superior in many cases to revocation. A revocation makes work for the Help Desk. An increasing delay would be arguably as effective and have the advantage that you cite. RFE? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, January 21, 2020 10:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM AOAR O44855 There are two separate issues: 1. Should you only say that the userid/password combinations is bad? I have no problem with that. 2. Should you auto-revoke after n failed attempts? That's the vector for the DOS attack. IMHO it makes more sense to introduce an exponential delay, block the IP address or some oapproach that makes it hader to deliberately suspend a batch of user ids. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM AOAR O44855
There are two separate issues: 1. Should you only say that the userid/password combinations is bad? I have no problem with that. 2. Should you auto-revoke after n failed attempts? That's the vector for the DOS attack. IMHO it makes more sense to introduce an exponential delay, block the IP address or some oapproach that makes it hader to deliberately suspend a batch of user ids. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, January 21, 2020 1:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM AOAR O44855 It's true. And there are various sources that will give the bad guy one or more candidate userid's -- with any luck a senior sysprog id -- for a given site. Think of the IBMMAIN archives, for example. Or sites where the user guide is available online. And with one ID it is not hard to bootstrap to other ID's. For example, if SYS005 is a good ID at some site, then SYS001-SYS0nn are all good candidates. It's still better than the alternative, a lowering of the name/password space from n*m to n+m. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, January 21, 2020 8:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM AOAR O44855 That opens the way to a denial of service attack; someone can write a script to cause revocation of a long list of userids. -- 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: IBM AOAR O44855
It's true. And there are various sources that will give the bad guy one or more candidate userid's -- with any luck a senior sysprog id -- for a given site. Think of the IBMMAIN archives, for example. Or sites where the user guide is available online. And with one ID it is not hard to bootstrap to other ID's. For example, if SYS005 is a good ID at some site, then SYS001-SYS0nn are all good candidates. It's still better than the alternative, a lowering of the name/password space from n*m to n+m. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, January 21, 2020 8:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM AOAR O44855 That opens the way to a denial of service attack; someone can write a script to cause revocation of a long list of userids. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH and IARV64
Thanks so much I was able to display the address under TEST using mark Zelden Rexmem exec ok let me re-look Thanks > On Jan 21, 2020, at 11:34 AM, Rob Scott wrote: > > Unlikely that TTOKEN is the cause (unless the task that issued IARV64 has > terminated). > > More likely that you have bad address somewhere in your code/logic. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Joseph Reichman > Sent: Tuesday, January 21, 2020 3:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ATTACH and IARV64 > > EXTERNAL EMAIL > > > > > > I got a soc4 pic 11 in a subtask > > I didn’t use the TTOKEN parameter > > Let me look again > > > Thanks > > > > > >> On Jan 21, 2020, at 10:42 AM, Rob Scott wrote: >> >> You do not need REQUEST=GETSHARED. >> >> IARV64 REQUEST=GETSTOR will suffice as the concept of "subpool" does not >> apply to 64-bit memory objects. >> >> The memory can be used by any task with the same address space as long as >> the owning task (see TTOKEN) is still active AND the REQ=DETACH has not been >> performed. >> >> REQUEST=GETSHARED is more suited to cross-address space sharing of memory >> objects where 64-bit common is not desired or required. >> >> See the "MVS Extended Addressability Guide" manual for more info >> >> Rob Scott >> Rocket Software >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Joseph Reichman >> Sent: Tuesday, January 21, 2020 3:19 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: ATTACH and IARV64 >> >> EXTERNAL EMAIL >> >> >> >> >> >> Under to 2GB bar the attach has a parameter SHSPV parameter to share >> storage or subpool with another task in the same address space >> >> >> >> Above the 2GB I am assuming I would need to do a GETSHARED request ? >> >> >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> Rocket Software, Inc. and >> subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll >> Free Number: +1 855.577.4323 Contact Customer Support: >> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.r >> ocketsoftware.com%2FRocketCommunity%2FRCEmailSupport&data=02%7C01% >> 7C%7Ce9327e37d9804258042708d79e892d65%7C79544c1eed224879a082b67a9a672a >> ae%7C0%7C0%7C637152184337173515&sdata=EOa40btQE9sbGr73NV1QW7vC40YL >> NNccMxh8j39HoOU%3D&reserved=0 Unsubscribe from Marketing >> Messages/Manage Your Subscription Preferences - >> https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.r >> ocketsoftware.com%2Fmanage-your-email-preferences&data=02%7C01%7C% >> 7Ce9327e37d9804258042708d79e892d65%7C79544c1eed224879a082b67a9a672aae% >> 7C0%7C0%7C637152184337173515&sdata=Xof8QfdKt3sleNW4aAhdjVT%2B646BE >> GRakcUBoem9GrQ%3D&reserved=0 Privacy Policy - >> https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.r >> ocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy&data=02%7C01% >> 7C%7Ce9327e37d9804258042708d79e892d65%7C79544c1eed224879a082b67a9a672a >> ae%7C0%7C0%7C637152184337173515&sdata=3vxuK4Xg0pcTjSv5EccyqBY4PLFq >> TQag3BmHf8PZz5o%3D&reserved=0 >> >> >> This communication and any attachments may contain confidential information >> of Rocket Software, Inc. All unauthorized use, disclosure or distribution is >> prohibited. If you are not the intended recipient, please notify Rocket >> Software immediately and destroy all copies of this communication. Thank you. >> >> -- >> 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
Re: IBM 3270 Font Available in Various Formats
+1 On Tue, Jan 21, 2020 at 10:58 Steve Smith wrote: > My favorite by far is Lucida Console for terminal screens and text editing; > except for Vista TN3270, where I just use its built-in bit-mapped fonts > (which are good too). > > Also, -1 for Courier :-) > > sas > > On Mon, Jan 20, 2020 at 8:28 PM Jesse 1 Robinson < > 02b46c9bbdf0-dmarc-requ...@listserv.ua.edu> wrote: > > > For some time I've been using Ariel Monospace for fixed font purposes. > > ... > > > > > J.O.Skip Robinson > > ... > > > > > Subject: (External):Re: IBM 3270 Font Available in Various Formats > > > > Recent Windows comes with a font called Consolas that I like for JCL > > examples and other monospaced usages. Less distracting IMHO than Courier > > with its gigantic serifs. > > > > https://en.wikipedia.org/wiki/Consolas > > > > Charles > > ... > > For those of you who'd like an "IBM 3270" font for various purposes, > > there's one available here: > > > > https://github.com/rbanffy/3270font > > > > Please check the license agreement: > > > > https://github.com/rbanffy/3270font/blob/master/LICENSE.txt > > > > Maybe this'll be a popular font for commands and code samples in future > > SHARE, GSE, and other presentations? :-) > > > > > > -- > 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: ATTACH and IARV64
Unlikely that TTOKEN is the cause (unless the task that issued IARV64 has terminated). More likely that you have bad address somewhere in your code/logic. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Tuesday, January 21, 2020 3:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH and IARV64 EXTERNAL EMAIL I got a soc4 pic 11 in a subtask I didn’t use the TTOKEN parameter Let me look again Thanks > On Jan 21, 2020, at 10:42 AM, Rob Scott wrote: > > You do not need REQUEST=GETSHARED. > > IARV64 REQUEST=GETSTOR will suffice as the concept of "subpool" does not > apply to 64-bit memory objects. > > The memory can be used by any task with the same address space as long as the > owning task (see TTOKEN) is still active AND the REQ=DETACH has not been > performed. > > REQUEST=GETSHARED is more suited to cross-address space sharing of memory > objects where 64-bit common is not desired or required. > > See the "MVS Extended Addressability Guide" manual for more info > > Rob Scott > Rocket Software > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > Sent: Tuesday, January 21, 2020 3:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: ATTACH and IARV64 > > EXTERNAL EMAIL > > > > > > Under to 2GB bar the attach has a parameter SHSPV parameter to share > storage or subpool with another task in the same address space > > > > Above the 2GB I am assuming I would need to do a GETSHARED request ? > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > Rocket Software, Inc. and > subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll > Free Number: +1 855.577.4323 Contact Customer Support: > https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.r > ocketsoftware.com%2FRocketCommunity%2FRCEmailSupport&data=02%7C01% > 7C%7Ce9327e37d9804258042708d79e892d65%7C79544c1eed224879a082b67a9a672a > ae%7C0%7C0%7C637152184337173515&sdata=EOa40btQE9sbGr73NV1QW7vC40YL > NNccMxh8j39HoOU%3D&reserved=0 Unsubscribe from Marketing > Messages/Manage Your Subscription Preferences - > https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.r > ocketsoftware.com%2Fmanage-your-email-preferences&data=02%7C01%7C% > 7Ce9327e37d9804258042708d79e892d65%7C79544c1eed224879a082b67a9a672aae% > 7C0%7C0%7C637152184337173515&sdata=Xof8QfdKt3sleNW4aAhdjVT%2B646BE > GRakcUBoem9GrQ%3D&reserved=0 Privacy Policy - > https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.r > ocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy&data=02%7C01% > 7C%7Ce9327e37d9804258042708d79e892d65%7C79544c1eed224879a082b67a9a672a > ae%7C0%7C0%7C637152184337173515&sdata=3vxuK4Xg0pcTjSv5EccyqBY4PLFq > TQag3BmHf8PZz5o%3D&reserved=0 > > > This communication and any attachments may contain confidential information > of Rocket Software, Inc. All unauthorized use, disclosure or distribution is > prohibited. If you are not the intended recipient, please notify Rocket > Software immediately and destroy all copies of this communication. Thank you. > > -- > 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: IBM AOAR O44855
That opens the way to a denial of service attack; someone can write a script to cause revocation of a long list of userids. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Barbara Nitz Sent: Tuesday, January 21, 2020 2:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM AOAR O44855 >Is anyone using this feature >https://www-01.ibm.com/support/docview.wss?uid=isg1OA44855 I implemented TSO PrePrompt when I was RACF Admin. If someone is attempting to hack into the mainframe using userid/password, I didn't want them to know if their userid was wrong or their password. After x invalid combinations (x is whatever your amount of allowed invalid passwords is before revoking you) the userid gets revoked, as before. It threw off the session manager we used to use back then, and it threw off a screenscraper that the compliance department uses (screenscraper=shudder). Both got around it. Barbara -- 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: Rexx or similar to clone a RACF user?
Sorry, IRRDUB00 is not sufficient. It's the first step used by a REXX program named DBSYNC. You'll need to download it and use IRRDUB00's output from your current RACF database as the "old file" (INDD1) and a dummy file as the "new file" (INDD2) as input to DBSYNC. It's DBSYNC that generates the RACF statements. Googling "RACF" "DBSYNC" will get you the information you need. Wendell Lovewell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM 3270 Font Available in Various Formats
My favorite by far is Lucida Console for terminal screens and text editing; except for Vista TN3270, where I just use its built-in bit-mapped fonts (which are good too). Also, -1 for Courier :-) sas On Mon, Jan 20, 2020 at 8:28 PM Jesse 1 Robinson < 02b46c9bbdf0-dmarc-requ...@listserv.ua.edu> wrote: > For some time I've been using Ariel Monospace for fixed font purposes. > ... > J.O.Skip Robinson > ... > Subject: (External):Re: IBM 3270 Font Available in Various Formats > > Recent Windows comes with a font called Consolas that I like for JCL > examples and other monospaced usages. Less distracting IMHO than Courier > with its gigantic serifs. > > https://en.wikipedia.org/wiki/Consolas > > Charles > ... > For those of you who'd like an "IBM 3270" font for various purposes, > there's one available here: > > https://github.com/rbanffy/3270font > > Please check the license agreement: > > https://github.com/rbanffy/3270font/blob/master/LICENSE.txt > > Maybe this'll be a popular font for commands and code samples in future > SHARE, GSE, and other presentations? :-) > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH and IARV64
I got a soc4 pic 11 in a subtask I didn’t use the TTOKEN parameter Let me look again Thanks > On Jan 21, 2020, at 10:42 AM, Rob Scott wrote: > > You do not need REQUEST=GETSHARED. > > IARV64 REQUEST=GETSTOR will suffice as the concept of "subpool" does not > apply to 64-bit memory objects. > > The memory can be used by any task with the same address space as long as the > owning task (see TTOKEN) is still active AND the REQ=DETACH has not been > performed. > > REQUEST=GETSHARED is more suited to cross-address space sharing of memory > objects where 64-bit common is not desired or required. > > See the "MVS Extended Addressability Guide" manual for more info > > Rob Scott > Rocket Software > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Joseph Reichman > Sent: Tuesday, January 21, 2020 3:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: ATTACH and IARV64 > > EXTERNAL EMAIL > > > > > > Under to 2GB bar the attach has a parameter SHSPV parameter to share storage > or subpool with another task in the same address space > > > > Above the 2GB I am assuming I would need to do a GETSHARED request ? > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ > Main Office Toll Free Number: +1 855.577.4323 > Contact Customer Support: > https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport > Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - > http://www.rocketsoftware.com/manage-your-email-preferences > Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy > > > This communication and any attachments may contain confidential information > of Rocket Software, Inc. All unauthorized use, disclosure or distribution is > prohibited. If you are not the intended recipient, please notify Rocket > Software immediately and destroy all copies of this communication. Thank you. > > -- > 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: ATTACH and IARV64
You do not need REQUEST=GETSHARED. IARV64 REQUEST=GETSTOR will suffice as the concept of "subpool" does not apply to 64-bit memory objects. The memory can be used by any task with the same address space as long as the owning task (see TTOKEN) is still active AND the REQ=DETACH has not been performed. REQUEST=GETSHARED is more suited to cross-address space sharing of memory objects where 64-bit common is not desired or required. See the "MVS Extended Addressability Guide" manual for more info Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Tuesday, January 21, 2020 3:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ATTACH and IARV64 EXTERNAL EMAIL Under to 2GB bar the attach has a parameter SHSPV parameter to share storage or subpool with another task in the same address space Above the 2GB I am assuming I would need to do a GETSHARED request ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ATTACH and IARV64
Under to 2GB bar the attach has a parameter SHSPV parameter to share storage or subpool with another task in the same address space Above the 2GB I am assuming I would need to do a GETSHARED request ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx or similar to clone a RACF user?
It's might be a bit excessive, but if you have RACF administrator authority, and an editor that will edit what might be a very large file, you could run IRRDBU00 and create a sequential file containing definitions of pretty much everything in your database except certificates and passwords. Edit the output and look for all of the statements that have the userid in them. Extract them to another file, change all the old userid to new userid, and run them through a batch TSO step to create the new user. I use a PC editor named Kedit that will edit a file with millions of lines and quickly find all occurrences of a string. YMMV. Hope this helps, Wendell Lovewell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tape Problem
Hi Sam, Just got you message. The problem was fixed but this morning it came back. I’ll check with IBM and get back to you later today. Thanks for all your help. Dean Nai Senior z/OS Systems Programmer Technical Services Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 work: 603-271-1529 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system. On 1/19/20, 9:12 PM, "IBM Mainframe Discussion List on behalf of Sam Golob" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Hi Folks, > > I once wrote a package to audit tape differences between the IBM >3494 VTS and CA-1. It is on CBT Tape File 519. www.cbttape.org CBT >file. It converts the tape inventory of CA-1 and the VTS to a common >format, and compares them, reporting discrepancies. Hope it helps. >This seems to do what you want. > > All the best of everything to all of you. > >Sincerely, Sam > >-- >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
