Re: Mainframe user ID length
Tom Marchant wrote: >What is your point? The contents of in-stream data is not part of >JCL, any more than the contents of some other data set referenced >in a DD statement is. Paul Gilmartin wrote: >There's a qualitative difference. The Reader or Converter must >inspect every record of an in-stream data set, and the Interpreter >or Access Method must scan for substitutable symbols. Not so with >some other data set. >And the in-line data appear in the SUBMITted member commonly called >JCL. If anyone still cares, here's what I actually wrote: >If you want to pass a longer user ID to something else >using a different vocabulary, JCL isn't going to stop you. >Example: Try using JCL to invoke z/OS's FTP client to transfer a file to >an arbitrary FTP server, specifying a user ID longer than 8 characters. >Can it be done? Of course it can; it's perfectly routine. You just don't >use JES-related syntax, that's all. 100% true! If there's a complaint about something I wrote, OK, fine, but how about making sure it's a complaint about something I wrote? :-) Who says mainframe professionals aren't the most friendly, helpful individuals willing to go the extra mile (or kilometer) to help solve user problems? Why, they never say "Can't be done!" and refuse to help. That's just ridiculous. :-) :-) It's usually not this platform that's getting in the way of progress. Here's yet another such case. For over two decades (closer to three) we've been submitting JCL to JES2 or JES3 to do such (awful) things as sending and receiving files via FTP, with absolutely no trouble specifying a user ID that's longer than 8 characters. We haven't even given it a second thought, really. JCL hasn't and isn't standing in your way here, obviously. Since the OS/390 days you've been able to present a X.509 digital certificate to RACF in lieu of a user ID for authentication and authorization. These features aren't state secrets. If you have z/OS, you have in-stream data in JCL. (How long has that been?) You also have the IBM Directory Server for z/OS. If you have the z/OS Security Server, you have RACF client certificate authentication. If you don't like maximum 8 character user IDs, OK, don't trouble your users with them! There are other viable, sensible approaches available -- handed to you, really. Plenty of organizations are already using them and aren't troubling their users with maximum 8 character IDs. So let's cut the nonsense and start leading progress rather than inhibiting it, OK? A few more "Wow, that's pretty interesting!" remarks would be welcome. (Thanks, Bob.) Deal? And sure, if there's something missing that you want or need, by all means ask (IBM RFE). OK, back to problem solving - - - - - - - - - - Timothy Sipples I.T. 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: ispf save / restore swapbar ?
Not sure what a 'swapbar' is, but I guess it would have to be saved to your ISPF profile pool (ISPPROF) before you logoff and restored from there when you logon. If it has a ZVAR name, as in something like )INIT .ZVARS = '(ZCMD SPRJ1 LIBB SECTION SEGMENT ABLV ZWSBV BMODEV SMODEV PRMODE + MSGDBVE MSGDBVS RPTDBVE RPTDBVS LISTDBVE LISTDBVS DEVTYPB VOLSER)' you could try saving/restoring that. Cheers. On 05/05/2020 17:06, Mike Stramba wrote: > Is there a way to save the current swapbar contents, and restore it > on next logon ? > > Mike > > -- > 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: Serverpac job RACFDLTA
I've made a lot of use of DBSYNC over the years. But, since I made doing the Software Upgrade path, I don't have a new RACF db to compare with. Examining the RACFLIST job turned out to be simpler than I expected. Also, not nearly as much new stuff, as say there was going from z/OS 1.3 to 2.1 or OS/390 to z/OS > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of retired mainframer > Sent: Tuesday, May 05, 2020 1:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Serverpac job RACFDLTA > > If you don't get any better ideas, DBSYNC from the RACF Goodies page might > help > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Gibney, Dave > > Sent: Tuesday, May 05, 2020 11:01 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Serverpac job RACFDLTA > > > > I am installing the archived z/OS 2.3 Serverpac on a z/OS 2.1 system. > When I tried > > to merge my z/OS 2.1 configuration into the 2.3 configuration, I > > received > a message > > that the old was created by a level of the Installation dialogue too > > old > to merge. So I > > didn't get a RACFDLTA job generated. > >Given that the RACFDRV/RACFTGT jobs are 1. Not at all a good idea > > to > run as > > delivered. 2. A real pain to manually evaluate. 3. Even the RACLIST > > job is > going to be > > tedious to evaluate. > >I was wondering if someone could provide an example RACFDLTA job > > hat I > could > > muck and see if I can get some useful info from? > > > > cross posted to IBM-MAIN and RACF-L > > > > Dave Gibney > > -- > 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: Mainframe user ID length
On Tue, 5 May 2020 15:07:59 -0500, Tom Marchant wrote: >On Tue, 5 May 2020 15:03:06 +0800, Timothy Sipples wrote: > >>Shmuel Metz wrote: >>>Regardless of why it is coded that way, the code is in >>>the C/I and the error message comes from the C/I. >> >>Yes, and in-stream data is an intrinsic feature of the Job Control >>Language (JCL). It says so right here, among other places: >> >>https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zjcl/zjclt_exercise_crtNsubmitjob.htm > >What is your point? The contents of in-stream data is not part of JCL, any >more >than the contents of some other data set referenced in a DD statement is. > There's a qualitative difference. The Reader or Converter must inspect every record of an in-stream data set, and the Interpreter or Access Method must scan for substitutable symbols. Not so with some other data set. And the in-line data appear in the SUBMITted member commonly called JCL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using Windows ssh with z/OS
On Tue, 5 May 2020 13:12:44 -0500, Kirk Wolf wrote: > >"deploy" ? > "employ"? >ISTR that this is your favorite example of using DD's in the shell :-) > >cat //DD:MYDD > o FSVO "favorite". See Appendix K of the Command Ref. It's not supported; it may work by happenstance; if it breaks you get to keep both parts. o If it happens to work it's because of "cat" and not "sh". I'd expect it to behave alike under "bash". >On Tue, May 5, 2020 at 9:17 AM Paul Gilmartin wrote: > >> On Tue, 5 May 2020 08:56:59 -0500, Kirk Wolf wrote: >> >> >FWIW, I would love to use bash exclusively on z/OS, but without >> >_BPX_SHAREAS support: >> > >> >- there are things that you just can't do, like use DDs >> > >> Where does a shell employ DDs? >> >> >- the overhead for forking new address spaces is significant for many >> >tasks. >> > >> That seems to be an argument for retaining _BPX_SHAREAS support. >> And for a shell's using spawn() where possible rather than fork(). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Serverpac job RACFDLTA
If you don't get any better ideas, DBSYNC from the RACF Goodies page might help > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gibney, Dave > Sent: Tuesday, May 05, 2020 11:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Serverpac job RACFDLTA > > I am installing the archived z/OS 2.3 Serverpac on a z/OS 2.1 system. When I tried > to merge my z/OS 2.1 configuration into the 2.3 configuration, I received a message > that the old was created by a level of the Installation dialogue too old to merge. So I > didn't get a RACFDLTA job generated. >Given that the RACFDRV/RACFTGT jobs are 1. Not at all a good idea to run as > delivered. 2. A real pain to manually evaluate. 3. Even the RACLIST job is going to be > tedious to evaluate. >I was wondering if someone could provide an example RACFDLTA job hat I could > muck and see if I can get some useful info from? > > cross posted to IBM-MAIN and RACF-L > > Dave Gibney -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
On Tue, 5 May 2020 15:03:06 +0800, Timothy Sipples wrote: >Shmuel Metz wrote: >>Regardless of why it is coded that way, the code is in >>the C/I and the error message comes from the C/I. > >Yes, and in-stream data is an intrinsic feature of the Job Control >Language (JCL). It says so right here, among other places: > >https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zjcl/zjclt_exercise_crtNsubmitjob.htm What is your point? The contents of in-stream data is not part of JCL, any more than the contents of some other data set referenced in a DD statement is. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using Windows ssh with z/OS
Gil, "deploy" ? ISTR that this is your favorite example of using DD's in the shell :-) cat //DD:MYDD On Tue, May 5, 2020 at 9:17 AM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Tue, 5 May 2020 08:56:59 -0500, Kirk Wolf wrote: > > >FWIW, I would love to use bash exclusively on z/OS, but without > >_BPX_SHAREAS support: > > > >- there are things that you just can't do, like use DDs > > > Where does a shell employ DDs? > > >- the overhead for forking new address spaces is significant for many > >tasks. > > > That seems to be an argument for retaining _BPX_SHAREAS support. > And for a shell's using spawn() where possible rather than fork(). > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Serverpac job RACFDLTA
I am installing the archived z/OS 2.3 Serverpac on a z/OS 2.1 system. When I tried to merge my z/OS 2.1 configuration into the 2.3 configuration, I received a message that the old was created by a level of the Installation dialogue too old to merge. So I didn't get a RACFDLTA job generated. Given that the RACFDRV/RACFTGT jobs are 1. Not at all a good idea to run as delivered. 2. A real pain to manually evaluate. 3. Even the RACLIST job is going to be tedious to evaluate. I was wondering if someone could provide an example RACFDLTA job hat I could muck and see if I can get some useful info from? cross posted to IBM-MAIN and RACF-L Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Checkpoint Size 1.13 to 2.2
Try using $DACTIVATE command. Not sure if you can enter on 1.13 or if it needs to be done on 2.2. A larger CF and CKPT is needed due to the restructuring of the JES2 Spool. Is your 2.2 system at z11? Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Elaine Beal Sent: Tuesday, May 5, 2020 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES2 Checkpoint Size 1.13 to 2.2 We are migrating from 1.13 to 2.2 in a MAS sysplex. JES2 WARM start, no parm changes. Checkpoint in z11 mode. Of course I'm trying to get around having to define a separate JES on 2.2 LPAR A cold start is a possibility. Right now that's the only possible 'fix' that I see When I IPL the first LPAR on 2.2 (gotten around several errors) but now seeing an error on the CKPT size. Based on the message and doc I don't see any additional requirement. $HASP537 THE CURRENT CHECKPOINT USES--532 4K RECORDS $HASP710 this level is incompatible with one or more active members...meber is down-level I've gotten the down-level before but was able to identify the issue and get past it looking to do the same with this issue Details below. Thanks, Elaine $HASP537 JES2 issues a message during initialization to inform system programmers of the checkpoint size requirements for the current checkpoint configuration. If this is a cold start, the number is based on the parameters specified in the initialization deck. If this is a warm start the size is based on the current checkpoint configuration. >From displays below 532K is what is currently in use at around 90% free If the >message is based on SIZE requirements (not the 532K in use) what is the issue? Using the same JOENUM, JOBNUM, etc. Is there a parm that can be changed? It would be possible to update both 1.13 LPARs and do another 2.2 IPL Though not indicated, do I need to cold start? *** There is no doc indicating that 2.2 needs additional space. even if it did, there is plenty.*** *** but if it does need more, I can see it expecting to be using only 532K, same as the shared LPAR *** *** in which case would a 2.2 cold start update both 2.2 and 1.13 with same utilization? *** $D ACTIVATE JES2 CHECKPOINT MODE IS CURRENTLY Z11 THE CURRENT CHECKPOINT: -- CONTAINS 6100 BERTS AND BERT UTILIZATION IS 5 PERCENT. -- CONTAINS 532 4K RECORDS. $D CKPTSPACE $HASP852 CKPTSPACE $HASP852 CKPTSPACE BERTNUM=6100,BERTFREE=5752,BERTWA $HASP852CKPT1=(CAPACITY=7188,UNUSED=6660) $HASP852CKPT2=(CAPACITY=5388,UNUSED=4860) CF STRUCTURE NAME(AAAMVSP_CKPT1) SIZE(3456K) FULLTHRESHOLD(0) PREFLIST(M3KENG2) -- 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: JES2 Checkpoint Size 1.13 to 2.2
I guess I should have asked what are you trying to do? Do you want a z/OS V1.13 system using the same spool as the V2.2? Do you need to have the tasks in V1.13 moved to V2.2? You might want to consider doing a JES2 Offload then shutdown V1.13. Bring up your systems at V2.2 level and then reload your spool from V1.13 to V2.2 You may still need to increase the size of CKPT and/or CF Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Elaine Beal Sent: Tuesday, May 5, 2020 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES2 Checkpoint Size 1.13 to 2.2 We are migrating from 1.13 to 2.2 in a MAS sysplex. JES2 WARM start, no parm changes. Checkpoint in z11 mode. Of course I'm trying to get around having to define a separate JES on 2.2 LPAR A cold start is a possibility. Right now that's the only possible 'fix' that I see When I IPL the first LPAR on 2.2 (gotten around several errors) but now seeing an error on the CKPT size. Based on the message and doc I don't see any additional requirement. $HASP537 THE CURRENT CHECKPOINT USES--532 4K RECORDS $HASP710 this level is incompatible with one or more active members...meber is down-level I've gotten the down-level before but was able to identify the issue and get past it looking to do the same with this issue Details below. Thanks, Elaine $HASP537 JES2 issues a message during initialization to inform system programmers of the checkpoint size requirements for the current checkpoint configuration. If this is a cold start, the number is based on the parameters specified in the initialization deck. If this is a warm start the size is based on the current checkpoint configuration. >From displays below 532K is what is currently in use at around 90% free If the >message is based on SIZE requirements (not the 532K in use) what is the issue? Using the same JOENUM, JOBNUM, etc. Is there a parm that can be changed? It would be possible to update both 1.13 LPARs and do another 2.2 IPL Though not indicated, do I need to cold start? *** There is no doc indicating that 2.2 needs additional space. even if it did, there is plenty.*** *** but if it does need more, I can see it expecting to be using only 532K, same as the shared LPAR *** *** in which case would a 2.2 cold start update both 2.2 and 1.13 with same utilization? *** $D ACTIVATE JES2 CHECKPOINT MODE IS CURRENTLY Z11 THE CURRENT CHECKPOINT: -- CONTAINS 6100 BERTS AND BERT UTILIZATION IS 5 PERCENT. -- CONTAINS 532 4K RECORDS. $D CKPTSPACE $HASP852 CKPTSPACE $HASP852 CKPTSPACE BERTNUM=6100,BERTFREE=5752,BERTWA $HASP852CKPT1=(CAPACITY=7188,UNUSED=6660) $HASP852CKPT2=(CAPACITY=5388,UNUSED=4860) CF STRUCTURE NAME(AAAMVSP_CKPT1) SIZE(3456K) FULLTHRESHOLD(0) PREFLIST(M3KENG2) -- 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: tape drice or tape cart???
Wish it was that easy. But as I stated there are 12 TAPE DRIVES AVAILIABLE for this job. It is NOT a tape drive not available issue. (wish it was that easy, went down that path) Thank you for your response. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, May 05, 2020 1:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: tape drice or tape cart??? From: https://www.dellemc.com/en-us/collaterals/unauth/technical-guides-support-information/products/storage/docu95468.pdf DLS180I DRIVE IS ALREADY ALLOCATED or BOXED The device that is specified on the DEV= parameter is either already in use or is boxed and cannot be used. Select a different drive and retry the job. So it seems to be the drive, not the medium (tape). On Tue, May 5, 2020 at 11:54 AM CarlosM Martinez wrote: > I keep getting this message and I cannot seem to figure out what is going > on here we have a DELL TLM and there are 13 tape drives attached VA Z/VM > to this test MVS guest. Has anyone ever had this? > > DLMSCR VER 4.42 > DLS180I DRIVE IS ALREADY ALLOCATED or BOXED > +TL4000 009E REJECTED COMMAND FROM BATCH JOB VPPPDBEG: > +TL4000 006I SCRATCH VSN 800064 > +TL4000 057E VOLUME 800064 CANNOT BE SCRATCHED. > +TL4000 059E THE DLMSCR COMMAND FAILED WITH A RETURN CODE OF > +TL4000 053E SEE DMC.TL4000.D200503.T110302.U400544 FOR DETAI > > Thank you > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: tape drice or tape cart???
From: https://www.dellemc.com/en-us/collaterals/unauth/technical-guides-support-information/products/storage/docu95468.pdf DLS180I DRIVE IS ALREADY ALLOCATED or BOXED The device that is specified on the DEV= parameter is either already in use or is boxed and cannot be used. Select a different drive and retry the job. So it seems to be the drive, not the medium (tape). On Tue, May 5, 2020 at 11:54 AM CarlosM Martinez wrote: > I keep getting this message and I cannot seem to figure out what is going > on here we have a DELL TLM and there are 13 tape drives attached VA Z/VM > to this test MVS guest. Has anyone ever had this? > > DLMSCR VER 4.42 > DLS180I DRIVE IS ALREADY ALLOCATED or BOXED > +TL4000 009E REJECTED COMMAND FROM BATCH JOB VPPPDBEG: > +TL4000 006I SCRATCH VSN 800064 > +TL4000 057E VOLUME 800064 CANNOT BE SCRATCHED. > +TL4000 059E THE DLMSCR COMMAND FAILED WITH A RETURN CODE OF > +TL4000 053E SEE DMC.TL4000.D200503.T110302.U400544 FOR DETAI > > Thank you > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
tape drice or tape cart???
I keep getting this message and I cannot seem to figure out what is going on here we have a DELL TLM and there are 13 tape drives attached VA Z/VM to this test MVS guest. Has anyone ever had this? DLMSCR VER 4.42 DLS180I DRIVE IS ALREADY ALLOCATED or BOXED +TL4000 009E REJECTED COMMAND FROM BATCH JOB VPPPDBEG: +TL4000 006I SCRATCH VSN 800064 +TL4000 057E VOLUME 800064 CANNOT BE SCRATCHED. +TL4000 059E THE DLMSCR COMMAND FAILED WITH A RETURN CODE OF +TL4000 053E SEE DMC.TL4000.D200503.T110302.U400544 FOR DETAI Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Checkpoint Size 1.13 to 2.2 [EXTERNAL]
Making the CHECKPOINT bigger is not a bad idea, but I would also just verify you have all the needed PTFs applied to z/OS to allow a mix of z/OS 1.13 and z/OS 2.2 in the same JES2 MAS. - V=IBM P=Z/OS JES2 MESSAGES R=V1R13 I=$HASP710 D=M > Licensed for benefit of Money Services Inc < > * Text Below Copyright (c) 2020, IBM * $HASP710 Explanation: >>--THIS LEVEL OF JES2 IS-- INCOMPATIBLE WITH--reason> >> >--ONE OR MORE ACTIVE MEMBERS--MEMBER=--memname,--REASON=--reason> > >-- ,..., --MEMBER=--memname,--REASON=--reason-->< > During initialization processing, JES2 detected active members in the MAS that are incompatible with the initializing member. In the message text: memname The name of the active member that is incompatible with the initializing member. reason The reason that the active member is incompatible. The reason is one of the following: MEMBER IS DOWN-LEVEL The member is at a lower release than the initializing member. MEMBER IS UP-LEVEL The member is at a higher release than the initializing member. MEMBER LEVEL IS NOT SET The member level is not set. System Programmer Response: If the releases are compatible, compatibility PTFs may be required on either the initializing member or the members identified by the message. If the problem cannot be resolved, search problem reporting data bases for a fix for the problem. If no fix exists, contact the IBM Support Center. Detecting Module: HASPIRDA Routing Code: 1,2,10 Descriptor Code: 4
Re: JES2 Checkpoint Size 1.13 to 2.2
You will also need to redefine the Structure to correspond with the larger checkpoint sizes. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Elaine Beal Sent: Tuesday, May 5, 2020 11:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES2 Checkpoint Size 1.13 to 2.2 [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] We are migrating from 1.13 to 2.2 in a MAS sysplex. JES2 WARM start, no parm changes. Checkpoint in z11 mode. Of course I'm trying to get around having to define a separate JES on 2.2 LPAR A cold start is a possibility. Right now that's the only possible 'fix' that I see When I IPL the first LPAR on 2.2 (gotten around several errors) but now seeing an error on the CKPT size. Based on the message and doc I don't see any additional requirement. $HASP537 THE CURRENT CHECKPOINT USES--532 4K RECORDS $HASP710 this level is incompatible with one or more active members...meber is down-level I've gotten the down-level before but was able to identify the issue and get past it looking to do the same with this issue Details below. Thanks, Elaine $HASP537 JES2 issues a message during initialization to inform system programmers of the checkpoint size requirements for the current checkpoint configuration. If this is a cold start, the number is based on the parameters specified in the initialization deck. If this is a warm start the size is based on the current checkpoint configuration. From displays below 532K is what is currently in use at around 90% free If the message is based on SIZE requirements (not the 532K in use) what is the issue? Using the same JOENUM, JOBNUM, etc. Is there a parm that can be changed? It would be possible to update both 1.13 LPARs and do another 2.2 IPL Though not indicated, do I need to cold start? *** There is no doc indicating that 2.2 needs additional space. even if it did, there is plenty.*** *** but if it does need more, I can see it expecting to be using only 532K, same as the shared LPAR *** *** in which case would a 2.2 cold start update both 2.2 and 1.13 with same utilization? *** $D ACTIVATE JES2 CHECKPOINT MODE IS CURRENTLY Z11 THE CURRENT CHECKPOINT: -- CONTAINS 6100 BERTS AND BERT UTILIZATION IS 5 PERCENT. -- CONTAINS 532 4K RECORDS. $D CKPTSPACE $HASP852 CKPTSPACE $HASP852 CKPTSPACE BERTNUM=6100,BERTFREE=5752,BERTWA $HASP852CKPT1=(CAPACITY=7188,UNUSED=6660) $HASP852CKPT2=(CAPACITY=5388,UNUSED=4860) CF STRUCTURE NAME(AAAMVSP_CKPT1) SIZE(3456K) FULLTHRESHOLD(0) PREFLIST(M3KENG2) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Checkpoint Size 1.13 to 2.2
One your z/OS 1.13 system define new, larger, checkpoint datasets and perform the JES2 Checkpoint migration dialog. (Check the fine manuals. This is well documented. After running on the new checkpoints, you can then proceed w/the z/OS 2.2 implementation. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Elaine Beal Sent: Tuesday, May 5, 2020 11:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES2 Checkpoint Size 1.13 to 2.2 [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] We are migrating from 1.13 to 2.2 in a MAS sysplex. JES2 WARM start, no parm changes. Checkpoint in z11 mode. Of course I'm trying to get around having to define a separate JES on 2.2 LPAR A cold start is a possibility. Right now that's the only possible 'fix' that I see When I IPL the first LPAR on 2.2 (gotten around several errors) but now seeing an error on the CKPT size. Based on the message and doc I don't see any additional requirement. $HASP537 THE CURRENT CHECKPOINT USES--532 4K RECORDS $HASP710 this level is incompatible with one or more active members...meber is down-level I've gotten the down-level before but was able to identify the issue and get past it looking to do the same with this issue Details below. Thanks, Elaine $HASP537 JES2 issues a message during initialization to inform system programmers of the checkpoint size requirements for the current checkpoint configuration. If this is a cold start, the number is based on the parameters specified in the initialization deck. If this is a warm start the size is based on the current checkpoint configuration. From displays below 532K is what is currently in use at around 90% free If the message is based on SIZE requirements (not the 532K in use) what is the issue? Using the same JOENUM, JOBNUM, etc. Is there a parm that can be changed? It would be possible to update both 1.13 LPARs and do another 2.2 IPL Though not indicated, do I need to cold start? *** There is no doc indicating that 2.2 needs additional space. even if it did, there is plenty.*** *** but if it does need more, I can see it expecting to be using only 532K, same as the shared LPAR *** *** in which case would a 2.2 cold start update both 2.2 and 1.13 with same utilization? *** $D ACTIVATE JES2 CHECKPOINT MODE IS CURRENTLY Z11 THE CURRENT CHECKPOINT: -- CONTAINS 6100 BERTS AND BERT UTILIZATION IS 5 PERCENT. -- CONTAINS 532 4K RECORDS. $D CKPTSPACE $HASP852 CKPTSPACE $HASP852 CKPTSPACE BERTNUM=6100,BERTFREE=5752,BERTWA $HASP852CKPT1=(CAPACITY=7188,UNUSED=6660) $HASP852CKPT2=(CAPACITY=5388,UNUSED=4860) CF STRUCTURE NAME(AAAMVSP_CKPT1) SIZE(3456K) FULLTHRESHOLD(0) PREFLIST(M3KENG2) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ispf save / restore swapbar ?
Is there a way to save the current swapbar contents, and restore it on next logon ? Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/os d,a,l --- What does "owt" mean ?
Thx David. Mike On 5/1/20, David Spiegel wrote: > Swapped out, waiting, not ready to run. > (waiting for user to enter a command) > > On 2020-05-01 15:09, Mike Stramba wrote: >> When running the z/os console display command : d,a,l --- What >> does "owt" mean ? >> >> Seems to be associated with TSO processes ? >> >> Mike >> >> -- >> 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
JES2 Checkpoint Size 1.13 to 2.2
We are migrating from 1.13 to 2.2 in a MAS sysplex. JES2 WARM start, no parm changes. Checkpoint in z11 mode. Of course I'm trying to get around having to define a separate JES on 2.2 LPAR A cold start is a possibility. Right now that's the only possible 'fix' that I see When I IPL the first LPAR on 2.2 (gotten around several errors) but now seeing an error on the CKPT size. Based on the message and doc I don't see any additional requirement. $HASP537 THE CURRENT CHECKPOINT USES--532 4K RECORDS $HASP710 this level is incompatible with one or more active members...meber is down-level I've gotten the down-level before but was able to identify the issue and get past it looking to do the same with this issue Details below. Thanks, Elaine $HASP537 JES2 issues a message during initialization to inform system programmers of the checkpoint size requirements for the current checkpoint configuration. If this is a cold start, the number is based on the parameters specified in the initialization deck. If this is a warm start the size is based on the current checkpoint configuration. From displays below 532K is what is currently in use at around 90% free If the message is based on SIZE requirements (not the 532K in use) what is the issue? Using the same JOENUM, JOBNUM, etc. Is there a parm that can be changed? It would be possible to update both 1.13 LPARs and do another 2.2 IPL Though not indicated, do I need to cold start? *** There is no doc indicating that 2.2 needs additional space. even if it did, there is plenty.*** *** but if it does need more, I can see it expecting to be using only 532K, same as the shared LPAR *** *** in which case would a 2.2 cold start update both 2.2 and 1.13 with same utilization? *** $D ACTIVATE JES2 CHECKPOINT MODE IS CURRENTLY Z11 THE CURRENT CHECKPOINT: -- CONTAINS 6100 BERTS AND BERT UTILIZATION IS 5 PERCENT. -- CONTAINS 532 4K RECORDS. $D CKPTSPACE $HASP852 CKPTSPACE $HASP852 CKPTSPACE BERTNUM=6100,BERTFREE=5752,BERTWA $HASP852CKPT1=(CAPACITY=7188,UNUSED=6660) $HASP852CKPT2=(CAPACITY=5388,UNUSED=4860) CF STRUCTURE NAME(AAAMVSP_CKPT1) SIZE(3456K) FULLTHRESHOLD(0) PREFLIST(M3KENG2) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
On 5/4/2020 10:12 PM, Tom Brennan wrote: I don't think it matters much. If the PC gets hacked then the hacker can probably figure out ways to get access to the mainframe whether it's setup to automatically logon or not. Among the most popular workstation "malware" implants are so-called "key loggers" which record keystrokes and send them to your assailant. A great way to get userids & passwords! -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using Windows ssh with z/OS
On Tue, 5 May 2020 08:56:59 -0500, Kirk Wolf wrote: >FWIW, I would love to use bash exclusively on z/OS, but without >_BPX_SHAREAS support: > >- there are things that you just can't do, like use DDs > Where does a shell employ DDs? >- the overhead for forking new address spaces is significant for many >tasks. > That seems to be an argument for retaining _BPX_SHAREAS support. And for a shell's using spawn() where possible rather than fork(). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Using Windows ssh with z/OS
I tried this. Didn’t work for me.
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: Tuesday, May 5, 2020 9:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AW: Using Windows ssh with z/OS
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
On Tue, 5 May 2020 19:32:00 +0800, David Crayford wrote:
>
># switch to bash
>export SHELL=${BASH}
>exec ${BASH} --login
>
Why does that not loop?
Friendlier systems have a "chsh" command.
-- gil
--
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: zOSMF / zFS
What do you mean by ROOT? In sysplex file sharing the ROOT is the SYSPLEX root
that you create, which is typically very small, and only has the required ,
when not sharing ROOT is usually the filesystem IBM supplies. My sysplex root
contains (edited) mountpoints for each LPAR connecting, each possible z/OS
SYSRES, altroot, vendor sysres amongst others.
TEC1:$ cd /
TEC1:$ ls -al
total 616
lrwxrwxrwx1 0OMVSGRP9 Jun 4 2013 $SYSNAME -> $SYSNAME/
lrwxrwxrwx1 0OMVSGRP9 Jun 4 2013 $VERSION -> $VERSION/
drwxr-xr-x 52 0OMVSGRP 8192 Dec 26 2018 .
drwxr-xr-x 52 0OMVSGRP 8192 Dec 26 2018 ..
drwxr-xr-x2 0OMVSGRP0 Jun 4 2013 ...
drwxr-xr-x8 0OMVSGRP 8192 Jun 6 2013 DEV1
drwxr-xr-x9 0OMVSGRP 8192 Sep 19 2018 DEV2
drwxr-xr-x9 0OMVSGRP 8192 Sep 19 2018 NET1
drwxr-xr-x 13 0OMVSGRP 8192 Oct 21 2019 RSD01A
drwxr-xr-x 13 0OMVSGRP 8192 Oct 21 2019 RSD02A
drwxr-xr-x 52 0OMVSGRP 8192 Jun 1 2017 altroot
lrwxrwxrwx1 0OMVSGRP 12 Jun 4 2013 bin -> $VERSION/bin
lrwxrwxrwx1 0OMVSGRP 12 Jun 4 2013 dev -> $SYSNAME/dev
lrwxrwxrwx1 0OMVSGRP 12 Jun 4 2013 etc -> $SYSNAME/etc
dr-xr-xr-x 137 0TTY0 May 5 08:38 home
lrwxrwxrwx1 0OMVSGRP 12 Jun 4 2013 lib -> $VERSION/lib
drwxr-xr-x2 0OMVSGRP0 Jun 19 2014 null
lrwxrwxrwx1 0OMVSGRP 12 Jun 4 2013 opt -> $VERSION/opt
lrwxrwxrwx1 0OMVSGRP 25 Jun 6 2013 remote ->
$SYSSYMA/NFS//remote
lrwxrwxrwx1 0OMVSGRP 16 Jun 4 2013 samples -> $VERSION/samples
drwxr-xr-x6 0OMVSGRP 8192 Aug 30 2013 shared
lrwxrwxrwx1 0OMVSGRP 12 Jun 4 2013 tmp -> $SYSNAME/tmp
lrwxrwxrwx1 0OMVSGRP 10 Jun 6 2013 u -> $SYSNAME/u
lrwxrwxrwx1 0OMVSGRP 12 Jun 4 2013 usr -> $VERSION/usr
lrwxrwxrwx1 0OMVSGRP 12 Jun 4 2013 var -> $SYSNAME/var
lrwxrwxrwx1 0OMVSGRP 15 Aug 27 2013 vendor -> $SYSSYMA/
TEC1:$
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Beaver
Sent: Tuesday, May 5, 2020 9:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF / zFS
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
Thank you to all who have commented on this thread.
>From the comments and what I have read this is what I understand
My ROOT needs to be AUTOMOVE
I need to create ALTROOT
My zOSMF needs a PARM('RWSHARE') and UNMOUNT
such that it will shared across the SYSPLEX
My system has everything else as indicated by Allan Staller.
Have I missed anything in the thread or in what I have read
TIA
--
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 /
Re: zOSMF / zFS
It's a good idea to go through z/OS Version 2 Release 4 UNIX System Services
Planning, GA32-0884-40.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Steve Beaver [st...@stevebeaver.com]
Sent: Tuesday, May 5, 2020 9:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF / zFS
Thank you to all who have commented on this thread.
>From the comments and what I have read this is what I
understand
My ROOT needs to be AUTOMOVE
I need to create ALTROOT
My zOSMF needs a PARM('RWSHARE') and UNMOUNT
such that it will shared across the SYSPLEX
My system has everything else as indicated by Allan Staller.
Have I missed anything in the thread or in what I have read
TIA
--
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: Using Windows ssh with z/OS
FWIW, I would love to use bash exclusively on z/OS, but without _BPX_SHAREAS support: - there are things that you just can't do, like use DDs - the overhead for forking new address spaces is significant for many tasks. On Tue, May 5, 2020 at 8:06 AM David Crayford wrote: > To create terminfo colors check out Jerry Callens comment in this thread > > https://forum.rocketsoftware.com/t/no-colors-running-over-ssh-in-cygwin/1009/7 > > On 2020-05-05 8:11 PM, Michael Babcock wrote: > > After reading this thread I finally have my command line completion back! > > > > I have Rocket’s Bash installed, set my OMVS segment to the bash shell, > used > > Bluezone and created a ssh terminal session with VT320, set “disable > > dimming colors” and “Use ANSI colors” and set my screen to 32x120. I > then > > added export TERM=xterm to .profile and VIOLA! Tab command line > > completion! > > > > Thanks to all! > > > > On Sun, May 3, 2020 at 12:28 PM Michael Babcock > > wrote: > > > >> The thing I REALY miss in OMVS is command line completion with TAB key. > >> > >> On Sun, May 3, 2020 at 12:25 PM Paul Gilmartin < > >> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> > >>> On Sat, 2 May 2020 12:02:56 -0600, Jack J. Woehr wrote: > > But z/OS used to deny login when TERM was not in terminfo. > > Did it ever get better? > If it denies login to that term setting, you try something else :) > > >>> Yah, but I wished it had presumed something minimal such as TTY33 > >>> until I could EXPORT TERM and/or set TERMINFO. Catch-22: > >>> can't login without correct TERMINFO; can't set TERMINFO without > >>> logging in. > >>> > >>> And I once had an esoteric terminal for which the developer supplied > >>> a .terminfo source file. With octal escape sequences. I compiled it > >>> with /bin/tic. Guess why it didn't work. > >>> > >>> -- gil > >>> > >>> -- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >>> > >> -- > >> Michael Babcock > >> OneMain Financial > >> z/OS Systems Programmer, Lead > >> > > -- > 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: AW: Using Windows ssh with z/OS
On Tue, 5 May 2020 19:32:00 +0800, David Crayford wrote:
>
># switch to bash
>export SHELL=${BASH}
>exec ${BASH} --login
>
Why does that not loop?
Friendlier systems have a "chsh" command.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zOSMF / zFS
Thank you to all who have commented on this thread.
>From the comments and what I have read this is what I
understand
My ROOT needs to be AUTOMOVE
I need to create ALTROOT
My zOSMF needs a PARM('RWSHARE') and UNMOUNT
such that it will shared across the SYSPLEX
My system has everything else as indicated by Allan Staller.
Have I missed anything in the thread or in what I have read
TIA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using Windows ssh with z/OS
To create terminfo colors check out Jerry Callens comment in this thread https://forum.rocketsoftware.com/t/no-colors-running-over-ssh-in-cygwin/1009/7 On 2020-05-05 8:11 PM, Michael Babcock wrote: After reading this thread I finally have my command line completion back! I have Rocket’s Bash installed, set my OMVS segment to the bash shell, used Bluezone and created a ssh terminal session with VT320, set “disable dimming colors” and “Use ANSI colors” and set my screen to 32x120. I then added export TERM=xterm to .profile and VIOLA! Tab command line completion! Thanks to all! On Sun, May 3, 2020 at 12:28 PM Michael Babcock wrote: The thing I REALY miss in OMVS is command line completion with TAB key. On Sun, May 3, 2020 at 12:25 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: On Sat, 2 May 2020 12:02:56 -0600, Jack J. Woehr wrote: But z/OS used to deny login when TERM was not in terminfo. Did it ever get better? If it denies login to that term setting, you try something else :) Yah, but I wished it had presumed something minimal such as TTY33 until I could EXPORT TERM and/or set TERMINFO. Catch-22: can't login without correct TERMINFO; can't set TERMINFO without logging in. And I once had an esoteric terminal for which the developer supplied a .terminfo source file. With octal escape sequences. I compiled it with /bin/tic. Guess why it didn't work. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using Windows ssh with z/OS
After reading this thread I finally have my command line completion back! I have Rocket’s Bash installed, set my OMVS segment to the bash shell, used Bluezone and created a ssh terminal session with VT320, set “disable dimming colors” and “Use ANSI colors” and set my screen to 32x120. I then added export TERM=xterm to .profile and VIOLA! Tab command line completion! Thanks to all! On Sun, May 3, 2020 at 12:28 PM Michael Babcock wrote: > The thing I REALY miss in OMVS is command line completion with TAB key. > > On Sun, May 3, 2020 at 12:25 PM Paul Gilmartin < > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Sat, 2 May 2020 12:02:56 -0600, Jack J. Woehr wrote: >> > >> >> But z/OS used to deny login when TERM was not in terminfo. >> >> Did it ever get better? >> > >> >If it denies login to that term setting, you try something else :) >> > >> Yah, but I wished it had presumed something minimal such as TTY33 >> until I could EXPORT TERM and/or set TERMINFO. Catch-22: >> can't login without correct TERMINFO; can't set TERMINFO without >> logging in. >> >> And I once had an esoteric terminal for which the developer supplied >> a .terminfo source file. With octal escape sequences. I compiled it >> with /bin/tic. Guess why it didn't work. >> >> -- gil >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > -- > Michael Babcock > OneMain Financial > z/OS Systems Programmer, Lead > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Using Windows ssh with z/OS
On 2020-05-05 6:39 AM, Wendell Lovewell wrote:
Installing Rocket's bash provided the cursor history scrolling I was looking
for.
I don't perceive a difference between TERM=xterm+256color and TERM=xterm in the
command-line-only functions I use. (I don't see any coloring in the ls or
other output for either value.)'
bash doesn't add colors. "ls" is a system binary not a builtin. On linux
systems colors are supported in the GNU binaries and configured using
the LS_COLORS environment variable.
I have "bash" as the last line in /etc/profile. This seems to work, but I do have to enter "exit" twice to
close the window. Is there a way to invoke bash so that this is not necessary? I'm also not sure if this matters, but
"echo $SHELL" still shows "/bin/sh", not "/bin/bash".
Are you sure you want to configure /etc/profile to invoke bash for every
user? I would invoke it from the .profile config file in your home
directory.
This is how I do it:
# We want to switch to bash
BASH=/rsusr/ported/bin/bash
# switch to bash
export SHELL=${BASH}
exec ${BASH} --login
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
Shmuel Metz wrote: >Regardless of why it is coded that way, the code is in >the C/I and the error message comes from the C/I. Yes, and in-stream data is an intrinsic feature of the Job Control Language (JCL). It says so right here, among other places: https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zjcl/zjclt_exercise_crtNsubmitjob.htm Frank Swarbrick wrote: >On a separate line, are you saying is it possible for z/OS to use >a non-z/OS LDAP server for authentication (and authorization?), >including user IDs and passwords? "z/OS" is a big, grand place, so yes is the answer. For example, that's exactly what the z/OS Container Extensions do(es) if you simply turn on its LDAP feature. Naturally you do that from the z/OS Management Facility. >But this would that still require TSO and CICS (and IMS? and others?) >signon processes to be able to handle those user IDs? OK, now you're naming names (specific subsystems), and then "it depends." Let's pick CICS as an example. If you want to authenticate and authorize a user against a LDAP server (highly preferably the one on z/OS) for purposes of executing a CICS transaction, then one way to do that is to have a CICS Liberty region on the front side handling the job. CICS Liberty can definitely authenticate and authorize based on LDAP's guidance (with ID mapping), and there's some pretty good documentation explaining how to do that. TSO/E is "classic," and thus it understands up to 8 character maximum user IDs (up from 7 previously). However, as I sketched out, the end user need not necessarily know that. It'd be wonderful if somebody creates a TSO/E sign on screen analogous to z/VSE's that accepts a long user ID and passphrase which is then checked against LDAP on z/OS to decide whether to log the user on. LDAP on z/OS would then supply the mapped short name, without the user's active involvement. >What I would love to see is some sort of "single signon" option, >where a user would only need to sign on to their personal workstation >and not need to explicitly sign on to z/OS at all. There are many products that do that, including from IBM. - - - - - - - - - - Timothy Sipples I.T. 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: S0F9 and SOFD ABENDs and SVC dumps - oh my!
Hi Barbara, There seems to be a new command STOP REGION ABDUMP FORCE, but only for some status of ims regions: https://www.ibm.com/support/pages/apar/PH05432 But it is not properly documented, so we tried several things, but it did not work. DFSSTOP0 : Code has been modified to allow region to be cancelled by new command /STOP REG ABDUMP FORCE when region is in right status. A new DFS5060I error message will be issued if the region cannot be stopped as it is not in WAIT-INIT-INPROG or TERM-PENDING status.Maybe abdump needs to be issued first, but we have not tried this yet. Denis. -Original Message- From: Barbara Nitz To: IBM-MAIN@LISTSERV.UA.EDU Sent: Mon, May 4, 2020 10:23 am Subject: Re: S0F9 and SOFD ABENDs and SVC dumps - oh my! On Thu, 30 Apr 2020 09:09:32 -0400, Peter Relson wrote: > >z/OS FORCE did not work > > >Wanna bet? > >FORCE,ARM runs in the address space so would have been affected. >FORCE does not. Doesn't matter. With an IMS region, you cannot use cancel (z/OS: "non-cancelable, use force arm"). You cannot use force arm (z/OS: "cancel first, please"). And you cannot use force because IMS intercepts that and tells you to terminate the IMS region by de-registering it from IMS. Which doesn't work because it is already *unknown* (i.e. deregistered) in the control region, but the de-registering hasn't made it down the tcbs in that IMS message region. Sometimes the callrtm program worked after the 5th invocation, but sometimes it didn't work even after 10 invocations. (With the dumps to verify it didn't work in between invocations.) IMS message regions are BAD, IMHO. Regards, 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
