Re: Auto Reply on SDSF Console
Using SyzMPF/z you would only need to code 3 lines in the script for message
IEF455D:
IF WORD 02 = SP5145 | SP5146 | SP5147 | SP5149
Reply ,NO
ENDIF
We count the words of a message starting with zero as the messageid and (in
this case) the message itself is:
IEF455D MOUNT ser ON dev FOR jobname stepname OR REPLY ‘NO’
w0 w1 w2 w3 w4 w5 w6 w7 w8 w9w10
So the word you want to check for is word 2 (the ser in the above). The ""
is automagically filled in with the outstanding replyID presented in the
IEF455D message.
Not only are Syzygy automation products MUCH less expensive than any of the
other automation vendors, it's also a lot easier to use.
Brian
On Mon, 30 Nov 2020 11:15:20 +0300, saurabh khandelwal
wrote:
>Dear Group ,
>
>
>
>We have requirement to automate below manual reply comes in console every
>time, when we don’t find volume in our system and the standard reply to
>these message is *Reply id, NO.*
>
>
>10.14.03 JOB09020 *29 *IEF455D* MOUNT *SP5145* ON 0FAA FOR CASPLPRO SARBCH
>OR REPLY 'NO'l
>
>In this above message, whenever we get message id *IEF455D *on SDSF console
>and on 4th place in this line, we get volume name* SP5145 or SP5146 ,
>SP5147, SP5149 *then immediately using automation we should reply
>
>With* reply id, no.*
>
>
>
>In order to do this, we created
>
>
>
>IF MSGID = 'IEF455D'
>THEN
>
>EXEC(CMD('AUTREXX')) NETLOG(Y) SYSLOG(Y);
>
>
>
>
>
>Then into *'AUTREXX'* REXX side,
>
>
>
>
>
>
>
>/* REXX */
>
>trace r
>
>'PIPE SAFE * | STEM MSG.'
>
>TOvolume = Word( Msg,4 )
>
>MsgID = Word( Msg,1 )
>
>MsgID1 = substr(MsgID,2,2)
>
>
>
>volume = 'SP5145 ' ,
>
> 'SP5146 ' ,
>
>'SP5147 '
>
>
>
>Do i = 1 to Words(volume)
>
>comp_vol = Word(volume,i)
>
> If Strip(comp_vol) = TOvolume Then
>
>
>
>But unable to complete this logic in to REXX. Can you please help in
>building this REXX, which can help in replying on console once the above
>mentioned criteria matches.
>
>
>
>*Regards*
>
>*Saurabh*
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA Broadcom Replacement Software
You would need to talk to someone on that side of the place. Probably Henry Dee. If you send an offline email I can give you his address. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA Broadcom Replacement Software
Oh how I wish WebAuthn, password vault/manager, and MFA became commonplace. Would tie in great with the new HashiCorp Boundary - https://www.boundaryproject.io/ Maybe I'm just mish-mashing things in my head that don't actually fit together in the real world... - KB ‐‐‐ Original Message ‐‐‐ On Saturday, December 12, 2020 1:19 AM, Jesse 1 Robinson wrote: > I don't mean to sound like a salesman, there are a few pluses for TPX that I > have not seen mentioned. > > -- Sometimes a person has a unique userid or password on one app. For > example, I have a userid and password on a CICS region that is different from > my TSO credentials. TPX can map your credentials for an oddball app so that > you can log on seamlessly. > > -- TPX has (I think an add-on) feature to assist in changing password. If you > have apps on a dozen different SAF plexes, you can change your password in > TPX itself, then logon one by one to all other TPX-supported apps. TPX > recognizes that you just changed your password in that session, so as long as > the old password on an app is the same as the old TPX password, TPX will > automatically change the target password to match. You can rip through a > dozen apps in a minute. > > -- You can define different PFKeys to take you straight to particular > sessions--limited only by the number of PFKeys. > > I don't know of any emulator--even the best one--that can perform these > functions. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Steve Smith > > Sent: Thursday, December 10, 2020 1:15 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: CA Broadcom Replacement Software > > *** EXTERNAL EMAIL - Use caution when opening links or attachments *** > > fwiw, I use Vista TN3270, and almost exclusively for TSO. I typically have > 3-10 sessions at a time. Each runs its own window and process. It works quite > well, and each session can be sized (and sounded!... cowbell means this, > marimba means that) to suit. Kudos forever to Tom Brennan. fwiw, I am a > long-time paid customer, and will boldly state he doesn't charge as much as > he should (he might boldly state I can send him more money anytime I please). > > Long ago (if not so far away), I used TPX, but that was mainly back in the > real 327x days, and when VTAM was more than just a vestige. It was then a > killer app. The only advantage I can perceive now is the ability to recover > from network breakages more cleanly. Fortunately, that's not much of a > problem for me, and most systems patiently wait for me to reconnect anyway. > > I do wish I wasn't afflicted and infected with Windows, but that's a > different off-topic, and doesn't really affect 3270 emulation much. > > sas > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA Broadcom Replacement Software
Thanks Mitch, just personal curiosity. I love independent mainframe shops, a job at one is the dream! - KB ‐‐‐ Original Message ‐‐‐ On Friday, December 11, 2020 8:01 PM, Mitch Mccluhan wrote: > KB, > > The company is RES, out of Italy. They work independently or with IBM to > replace workload schedulers. Their web site is www.res-it.com. I have had a > relationship with them for over 20 years. I can put you in touch with the > right person within RES if you have questions or would like to learn more > about their automated scheduler conversion/migration solution. > > Regards, > > Mitch > > -Original Message- > From: kekronbekron <02dee3fcae33-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Thu, Dec 10, 2020 9:26 pm > Subject: Re: CA Broadcom Replacement Software > > Hi Mitch, > > What product is this.. ? > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Thursday, December 10, 2020 5:33 PM, Mitch Mccluhan > <005d889cebf0-dmarc-requ...@listserv.ua.edu> wrote: > >> Hello, >> In regards to automated scheduler replacements, I am aware of a company that >> does conversion/migration from a variety of scheduling software (CA-7, >> CA-Scheduler, Control-M, etc.) to the IBM IWS tool suite (formerly OPC or >> TWS). It is an automated conversion/migration that has been performed at a >> number of mainframe sites around the globe. >> >> Mitch McCluhan >> >> -Original Message- >> From: Patti Bowman patti.bow...@unicomglobal.com >> To: IBM-MAIN@LISTSERV.UA.EDU >> Sent: Wed, Dec 9, 2020 4:28 pm >> Subject: FW: CA Broadcom Replacement Software >> >> Hi: >> >> UNICOM/Macro 4 have a Session Manager to replace CA Broadcom'sTPX with a >> product called Tubes. Please see the link below: >> >> https://www.macro4.com/products/tubes-zos/ >> >> Thank you, >> Patti >> >> -Original Message- >> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of >> Richards, Robert B. (CTR) >> Sent: Wednesday, December 9, 2020 2:34 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: CA Broadcom Replacement Software >> >> I forgot to mention that they are all orderable on a ServerPAC and, at a >> minimum, sub-capacity eligible. >> >> -Original Message- >> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of >> Lizette Koehler >> Sent: Wednesday, December 9, 2020 2:29 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: CA Broadcom Replacement Software >> >> I think SuperSession for CA-TPX >> IBM's RMM for CA1 >> As for CA Workload Automation - There should be requirements to determine >> how to replace it >> >> IBM has a Tivoli Scheduler (I forget the name) But there are probably other >> companies. >> >> I would guess a Cost analysis should be done to see what makes sense. >> >> So CA Worklaod Automation is the top of the line, but CA also has Jobtrac >> >> Check out http://www.syzygyinc.com/as well >> >> It will come down to what do you need vs. what is available on the mark. >> >> Lizette >> >> -Original Message- >> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of >> Pommier, Rex >> Sent: Wednesday, December 9, 2020 12:18 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: CA Broadcom Replacement Software >> >> I'm going to slightly disagree with the multi windows instead of a session >> manager. Session manager gets closer to a single signon because it can mask >> signing on to everything. It also typically has a longer timeout and can >> seemingly withstand a network drop. I'm currently experiencing multiple WAN >> drops to work daily. My TN3270 sessions lose connectivity when the network >> drops so once the network is back I have to disconnect/reconnect my TN3270 >> connections but our session manager just drops me right back where I was. >> >> Rex >> >> -Original Message- >> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of >> Gibney, Dave >> Sent: Wednesday, December 9, 2020 1:09 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: [External] Re: CA Broadcom Replacement Software >> >> DFRMM for CA-1 >> Multiple tn3270 windows instead of any session manager >> >> > -Original Message- >> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On >> > Behalf Of Elaine Beal >> > Sent: Wednesday, December 09, 2020 11:07 AM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: CA Broadcom Replacement Software >> > Any recommendations for CA1, CA Workload Automation (JSS/ESP), TPX >> > session manager replacements? >> > >> > 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 >> >> The information contained in this message is confidential, protected from >> disclosure and may be legally privileged. If the reader of this
Re: CA Broadcom Replacement Software
Hi Brian, By any chance, is Syzygy Inc hiring, for 'facilities management' roles? - KB ‐‐‐ Original Message ‐‐‐ On Friday, December 11, 2020 11:22 AM, Brian Westerman wrote: > I hate this to be a marketing email, but I wanted to point out that the > Syzygy Automation package from Syzygy Incorporated is much cheaper and has > better/more features than most of the others available, and also happens to > be a lot cheaper. We currently have over 300 sites running some parts or all > of it. Plus as an IBM-Main participant, you also get 50% off for as long as > you license the product(s). www.syzygyInc.com > > As far as CA-1 is concerned IBM's RMM is every bit as good and almost always > works out to be cheaper. > > For session manager software, Mackinney has one that is works quite nice one > called VTAM Switch which I maintain at several of the sites we do facilities > management for and it's a really solid product. > > > > 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: JCL EXEC name field?
I saw that just today and was astounded! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, December 11, 2020 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JCL EXEC name field? In the JCL Ref.: Chapter 16. EXEC statement ... Name field ... • The stepname may be preceded by up to 8 alphanumeric or national characters and then separated by a period. If the stepname is coded in this way, the characters up to and including the period are ignored. WTF? A way of coding a very short comment? Is "." OK? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JCL EXEC name field?
In the JCL Ref.: Chapter 16. EXEC statement ... Name field ... • The stepname may be preceded by up to 8 alphanumeric or national characters and then separated by a period. If the stepname is coded in this way, the characters up to and including the period are ignored. WTF? A way of coding a very short comment? Is "." OK? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How test correct procstep RC with JCL IF?
>> What is "might be unpredictable"? How is that different from "are >> unpredictable"? > That just means that it's unpredictable whether it's unpredictable; I think we need an RCF to clarify whether it is unpredictable or not. Hey, it's Friday. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, December 11, 2020 1:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How test correct procstep RC with JCL IF? On Fri, 11 Dec 2020 12:32:10 -0800, Charles Mills wrote: >"Note that if stepnames are >not unique within the job, such as when the same procedure is executed multiple >times, results might be unpredictable; but in most cases, references to >non-unique >stepnames will resolve to the first occurrence of that stepname." > >Does not give me a warm and fuzzy feeling. > Reminds me of the several contributors here who insist that "//DD:name" is safe for UNIX utilities documented only as supporting "//data.set.name" because that's how fopen() works. Even for utilities not documented as relying on fopen(). >What is "might be unpredictable"? How is that different from "are >unpredictable"? > That just means that it's unpredictable whether it's unpredictable; not guaranteed to be unpredictable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How test correct procstep RC with JCL IF?
On Fri, 11 Dec 2020 12:32:10 -0800, Charles Mills wrote: >"Note that if stepnames are >not unique within the job, such as when the same procedure is executed multiple >times, results might be unpredictable; but in most cases, references to >non-unique >stepnames will resolve to the first occurrence of that stepname." > >Does not give me a warm and fuzzy feeling. > Reminds me of the several contributors here who insist that "//DD:name" is safe for UNIX utilities documented only as supporting "//data.set.name" because that's how fopen() works. Even for utilities not documented as relying on fopen(). >What is "might be unpredictable"? How is that different from "are >unpredictable"? > That just means that it's unpredictable whether it's unpredictable; not guaranteed to be unpredictable. I've argued here that the indolent developers should get to work and make any use of an "unpredictable" construct a JCL error. That has no impact on compatibility; an unexpected JCL error is covered by "unpredictable". Think robust programming. Peter R, with True Blue indolence, has rebutted that those unpredictable constructs are reserved for IBM internal use or for future extensions. I'm skeptical. I've long felt that responsible design should have required that the name fields on corresponding IF, THEN, ELSE, and ENDIF be identical, on pain of JCL error, for verifying correct conditional nesting. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How test correct procstep RC with JCL IF?
Well, it should be easy enough to test. I get your point about depnding on undocumented bahavior. It's something of a judgement call as to how likely you think the behavior to be stable. For this particular case, I'd presume that if it works now, it always will. It *should* be consistent with DSN refer-back and COND. If it is, then I'd count on it. sas On Fri, Dec 11, 2020 at 3:10 PM Charles Mills wrote: > I wondered about that, but how do I test that? It is not documented. If it > seems to work once, is that a good enough test? Twice? Five times? How do I > know whether it will work if other things in the PROC or JOB change? > > "Hopefully" is not a great testing philosophy. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Steve Smith > Sent: Friday, December 11, 2020 11:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: How test correct procstep RC with JCL IF? > > You may be over-thinking it. I know refer-backs to a stepname stay inside > a particular PROC invocation, so hopefully, the same rule applies to IF. > > -- > 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: How test correct procstep RC with JCL IF?
"Note that if stepnames are not unique within the job, such as when the same procedure is executed multiple times, results might be unpredictable; but in most cases, references to non-unique stepnames will resolve to the first occurrence of that stepname." Does not give me a warm and fuzzy feeling. What is "might be unpredictable"? How is that different from "are unpredictable"? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, December 11, 2020 12:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How test correct procstep RC with JCL IF? I wondered about that, but how do I test that? It is not documented. If it seems to work once, is that a good enough test? Twice? Five times? How do I know whether it will work if other things in the PROC or JOB change? "Hopefully" is not a great testing philosophy. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Friday, December 11, 2020 11:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How test correct procstep RC with JCL IF? You may be over-thinking it. I know refer-backs to a stepname stay inside a particular PROC invocation, so hopefully, the same rule applies to IF. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How test correct procstep RC with JCL IF?
QED! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jeremy Nicoll Sent: Friday, December 11, 2020 12:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How test correct procstep RC with JCL IF? On Fri, 11 Dec 2020, at 20:01, Charles Mills wrote: > //FOO EXEC MYPROC,PRM1=A,PRM2=B,LBL=FOO > //FOO EXEC MYPROC,PRM1=C,PRM2=D,LBL=BAR > > It's an invitation to errors. So I see. Shouldn't the last line have been //BAR EXEC MYPROC,PRM1=C,PRM2=D,LBL=BAR -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How test correct procstep RC with JCL IF?
On Fri, 11 Dec 2020, at 20:01, Charles Mills wrote: > //FOO EXEC MYPROC,PRM1=A,PRM2=B,LBL=FOO > //FOO EXEC MYPROC,PRM1=C,PRM2=D,LBL=BAR > > It's an invitation to errors. So I see. Shouldn't the last line have been //BAR EXEC MYPROC,PRM1=C,PRM2=D,LBL=BAR -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How test correct procstep RC with JCL IF?
I wondered about that, but how do I test that? It is not documented. If it seems to work once, is that a good enough test? Twice? Five times? How do I know whether it will work if other things in the PROC or JOB change? "Hopefully" is not a great testing philosophy. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Friday, December 11, 2020 11:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How test correct procstep RC with JCL IF? You may be over-thinking it. I know refer-backs to a stepname stay inside a particular PROC invocation, so hopefully, the same rule applies to IF. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How test correct procstep RC with JCL IF?
Well, I solved it //MYPROC PROC PRM1=,PRM2=,LBL= //STEP1 EXEC PGM= etc. // IF ( = 4) THEN //STEP2 EXEC PGM= etc. // ENDIF //FOO EXEC MYPROC,PRM1=A,PRM2=B,LBL=FOO //FOO EXEC MYPROC,PRM1=C,PRM2=D,LBL=BAR It's an invitation to errors. You have to code the label twice: once as the label of the procstep and once in LBL=. They did an incomplete job on symbols. If a PROC had access to a symbol it would solve this problem. In the same vein, I just voted up an RFE to add a symbol for the return code(s). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, December 11, 2020 11:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How test correct procstep RC with JCL IF? Oh for gosh sakes! I had the bright idea of passing a unique label for IF to test so the PROC becomes //MYPROC PROC PRM1=,PRM2=,LBL= // EXEC PGM= etc. // IF ( = 4) THEN //STEP2 EXEC PGM= etc. // ENDIF //X EXEC MYPROC,PRM1=A,PRM2=B,LBL=FOO //Y EXEC MYPROC,PRM1=C,PRM2=D,LBL=BAR But no! 9 IEFC662I INVALID LABEL Apparently you can't use a symbol for a step name? Is that right? G. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, December 11, 2020 7:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How test correct procstep RC with JCL IF? I want to have a PROC //MYPROC PROC PRM1=,PRM2= //STEP1 EXEC PGM= etc. // IF (STEP1.RC = 4) THEN //STEP2 EXEC PGM= etc. // ENDIF And then in a job execute the PROC several times: //X EXEC MYPROC,PRM1=A,PRM2=B //Y EXEC MYPROC,PRM1=C,PRM2=D Question: Will the IF in the proc test the RC for the STEP1 in that execution of the proc? Or some other execution of the PROC, perhaps the first? Is there a way to make it test "its own" STEP1.RC? Something kind of like (*.STEP1.RC = 4) ? I don't see any examples in the JCL manual of IF statements inside a PROC. Thanks, Charles -- 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: CA Broadcom Replacement Software
I don't mean to sound like a salesman, there are a few pluses for TPX that I have not seen mentioned. -- Sometimes a person has a unique userid or password on one app. For example, I have a userid and password on a CICS region that is different from my TSO credentials. TPX can map *your* credentials for an oddball app so that you can log on seamlessly. -- TPX has (I think an add-on) feature to assist in changing password. If you have apps on a dozen different SAF plexes, you can change your password in TPX itself, then logon one by one to all other TPX-supported apps. TPX recognizes that you just changed your password in that session, so as long as the old password on an app is the same as the old TPX password, TPX will automatically change the target password to match. You can rip through a dozen apps in a minute. -- You can define different PFKeys to take you straight to particular sessions--limited only by the number of PFKeys. I don't know of any emulator--even the best one--that can perform these functions. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Smith Sent: Thursday, December 10, 2020 1:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: CA Broadcom Replacement Software *** EXTERNAL EMAIL - Use caution when opening links or attachments *** fwiw, I use Vista TN3270, and almost exclusively for TSO. I typically have 3-10 sessions at a time. Each runs its own window and process. It works quite well, and each session can be sized (and sounded!... cowbell means this, marimba means that) to suit. Kudos forever to Tom Brennan. fwiw, I am a long-time paid customer, and will boldly state he doesn't charge as much as he should (he might boldly state I can send him more money anytime I please). Long ago (if not so far away), I used TPX, but that was mainly back in the real 327x days, and when VTAM was more than just a vestige. It was then a killer app. The only advantage I can perceive now is the ability to recover from network breakages more cleanly. Fortunately, that's not much of a problem for me, and most systems patiently wait for me to reconnect anyway. I do wish I wasn't afflicted and infected with Windows, but that's a different off-topic, and doesn't really affect 3270 emulation much. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How test correct procstep RC with JCL IF?
You may be over-thinking it. I know refer-backs to a stepname stay inside a particular PROC invocation, so hopefully, the same rule applies to IF. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How test correct procstep RC with JCL IF?
On Fri, 11 Dec 2020 11:13:31 -0800, Charles Mills wrote: >Oh for gosh sakes! > >I had the bright idea of passing a unique label for IF to test so the PROC >becomes > >//MYPROC PROC PRM1=,PRM2=,LBL= >// EXEC PGM= etc. >// IF ( = 4) THEN >//STEP2 EXEC PGM= etc. >// ENDIF > >//X EXEC MYPROC,PRM1=A,PRM2=B,LBL=FOO >//Y EXEC MYPROC,PRM1=C,PRM2=D,LBL=BAR > >But no! > >9 IEFC662I INVALID LABEL > >Apparently you can't use a symbol for a step name? Is that right? > True rather than right. I hadda lookitup. In the JCL Ref.: Rules for coding symbols in JCL Follow these rules when coding symbols in JCL: ... 4. Do not use symbols to change the identifier field, name field, or operation field of a JCL statement. JCL specification was written by the infinite number of monkeys who didn't grasp orthogonality. Even worse are the rules for overrides and referbacks to nested PROC calls. I recognize that immutable structure of control blocks allows for only two levels. The restriction could have been eased by generated procprocstep names. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How test correct procstep RC with JCL IF?
Nope, not permitted. Assembler supports that syntax but not JCL. Peter (Queue Gil's expected response: I HATE JCL!) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Friday, December 11, 2020 2:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How test correct procstep RC with JCL IF? Oh for gosh sakes! I had the bright idea of passing a unique label for IF to test so the PROC becomes //MYPROC PROC PRM1=,PRM2=,LBL= // EXEC PGM= etc. // IF ( = 4) THEN //STEP2 EXEC PGM= etc. // ENDIF //X EXEC MYPROC,PRM1=A,PRM2=B,LBL=FOO //Y EXEC MYPROC,PRM1=C,PRM2=D,LBL=BAR But no! 9 IEFC662I INVALID LABEL Apparently you can't use a symbol for a step name? Is that right? G. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, December 11, 2020 7:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How test correct procstep RC with JCL IF? I want to have a PROC //MYPROC PROC PRM1=,PRM2= //STEP1 EXEC PGM= etc. // IF (STEP1.RC = 4) THEN //STEP2 EXEC PGM= etc. // ENDIF And then in a job execute the PROC several times: //X EXEC MYPROC,PRM1=A,PRM2=B //Y EXEC MYPROC,PRM1=C,PRM2=D Question: Will the IF in the proc test the RC for the STEP1 in that execution of the proc? Or some other execution of the PROC, perhaps the first? Is there a way to make it test "its own" STEP1.RC? Something kind of like (*.STEP1.RC = 4) ? I don't see any examples in the JCL manual of IF statements inside a PROC. Thanks, Charles This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How test correct procstep RC with JCL IF?
Oh for gosh sakes! I had the bright idea of passing a unique label for IF to test so the PROC becomes //MYPROC PROC PRM1=,PRM2=,LBL= // EXEC PGM= etc. // IF ( = 4) THEN //STEP2 EXEC PGM= etc. // ENDIF //X EXEC MYPROC,PRM1=A,PRM2=B,LBL=FOO //Y EXEC MYPROC,PRM1=C,PRM2=D,LBL=BAR But no! 9 IEFC662I INVALID LABEL Apparently you can't use a symbol for a step name? Is that right? G. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, December 11, 2020 7:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How test correct procstep RC with JCL IF? I want to have a PROC //MYPROC PROC PRM1=,PRM2= //STEP1 EXEC PGM= etc. // IF (STEP1.RC = 4) THEN //STEP2 EXEC PGM= etc. // ENDIF And then in a job execute the PROC several times: //X EXEC MYPROC,PRM1=A,PRM2=B //Y EXEC MYPROC,PRM1=C,PRM2=D Question: Will the IF in the proc test the RC for the STEP1 in that execution of the proc? Or some other execution of the PROC, perhaps the first? Is there a way to make it test "its own" STEP1.RC? Something kind of like (*.STEP1.RC = 4) ? I don't see any examples in the JCL manual of IF statements inside a PROC. Thanks, Charles -- 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: DFSORT Header + Detail count match
> I coded the below DFSORT job , but it is not working . Could some
> one please let me know where the issue is ?
There are couple of issues with your job.
1. COUNT-n field is limited to 15 digits and you are creating a 17 byte
field which would have 2 spaces to the left of the count making the symbol
definition invalid
2. You created a display-able 17 byte count which is Zoned Decimal count
field , but you comparing that symbol using BINARY . The comparison will
be false
3. You do realize that coding RC16=ABE will make the job abend with U0206
abend if the counts do not match?
So change STEP01 SYSIN to use an EDIT mask insted of M11 mask. See
below
TRAILER1=('DATA_COUNT,+',COUNT-1=(EDIT=(T)))
Change STEP02 sysin to have ZD instead of BI
INCLUDE COND=(01,17,ZD,EQ,DATA_COUNT)
Thanks,
Kolusu
DFSORT Development
IBM Corporation
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
Here is how to do an "earliest support for each opcode" document if anyone wants to pick up where I left off. - IIRC the assembler will generate a list of valid opcodes for the specified ZS- level. (If I am mistaken then stop reading now.) You want to generate such a list for each ZS-level you are interested in. - Load the opcodes supported by z14, z13, etc. each into a column in Excel. - Load the opcodes supported by z15 into a column on a spreadsheet page. Then in the adjacent column do a lookup in the columns described in the preceding bullet. If not found anywhere else, then say z15. If found only in the z14 column, then say z14. And so forth. Now you have a spreadsheet with every opcode and the earliest machine that supports it. - Convert that into a PDF or some similar format for sharing. - If you are more comfortable with Rexx than with Excel what I describe could be done with Rexx. Substitute "stem variable" for "column" in my directions. Or PL/I. Or your favorite language. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, December 11, 2020 7:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED Tachyon Web page says last updated 05/29/2010 11:06:28 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, December 9, 2020 4:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED On Wed, 9 Dec 2020 at 10:53, Charles Mills wrote: > > I have been thinking about this. It is a daunting project. I once set out to > develop a simple list of opcodes with their required minimum hardware level. > I wanted to be able to answer questions of the form "management wants this > product to be able to run on a z9. Can I use AHI?" In fact I think I asked > for help on this list, and promised to share any results. I abandoned the > effort! I decided it was easier just to code AHI and assemble with ZS-5 or > whatever and see if I got an error. That list is obviously just one > component of your product. There has been a list at http://www.tachyonsoft.com/inst390o.htm for many years. I'm not at all sure it's maintained these days, but I use it frequently as a quick reference. -- 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: Z15 zedc compression and CONNECT DIRECT, MFT compression
In my SMF experience ... If the triplet offset or count field is zero then the segment does not exist. End of story. If the triplet length field is zero then - For most SMF record types that means the segment does not exist. - For Db2, and perhaps a few other types, it means each segment contains its own length in the first halfword. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFSORT Header + Detail count match
Hi,
We are getting 1 3rd part file with the layout as follows. Here in header 1-17
bytes is the count followed by Pipe & Date. The Rest of the lines is the detail
lines .
The process should not proceed if the count in header is not matching with the
detail line count.
7|2020-12-09
980012589|04937|03448
980010506|04937|02698
980001772|04937|03288
000276258|04937|03788
980012589|04936|03448
980010506|04936|02698
980001772|04936|03288
I coded the below DFSORT job , but it is not working . Could some one please
let me know where the issue is ?
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=PNS2S3.T1.F1.F1,DISP=SHR
//SORTOUT DD DSN=&K,DISP=(,PASS),SPACE=(TRK,(1,1),RLSE)
//SYSIN DD *
SORT FIELDS=COPY
OUTFIL REMOVECC,NODETAIL,BUILD=(80X),
TRAILER1=('DATA_COUNT,+',COUNT-1=(M11,LENGTH=17))
/*
//STEP02 EXEC PGM=SORT,PARM='RC16=ABE'
//SYSOUT DD SYSOUT=*
//SYMNAMES DD DSN=&K,DISP=SHR
//SORTIN DD DSN=PNS2S3.T1.F1.F1,DISP=SHR
//SORTOUT DD SYSOUT=*
//SYSINDD *
OPTION COPY,NULLOUT=RC16,STOPAFT=1
INCLUDE COND=(01,17,BI,EQ,DATA_COUNT)
//*
Regards
Ron T
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Z15 zedc compression and CONNECT DIRECT, MFT compression
Duh, Go to OFFSET and INPUT the LENGTH field.
Barry
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Barry Merrill
Sent: Friday, December 11, 2020 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Z15 zedc compression and CONNECT DIRECT, MFT compression
It is very common for SMF "Triplets" of Offset, Length, and Count to
populate the OFFSET, but to not populate the Count for segments that do not
exist in the record. And there can be more than one triplets with that same
OFFSET populated but with Counts zero.
It is also common to see segments that are present with OFFSET and COUNT
populated but with the LENGTH zero, which means you have to go to OFFSET and
INPUT the count field to process those segments.
Barry
Herbert W Barry Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966
ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Jousma, David
Sent: Wednesday, December 9, 2020 12:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Z15 zedc compression and CONNECT DIRECT, MFT compression
If you are using MXG with SAS, its likely you might need an update there?
_
Dave Jousma
AVP | Director, Technology 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
Kenneth J. Kripke
Sent: Wednesday, December 9, 2020 12:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Z15 zedc compression and CONNECT DIRECT, MFT compression
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or
unexpected emails**
Hello;
We have upgraded from a Z14 to Z15 processor, and, have experienced
something curious regarding the SMF TYPE 30 section being generated for
Connect Direct as well as Tibco's MFT 8.0 file transfer products.
Both products are enabled to use ZEDC compression, but, when generating SAS
reports from SMF type 30 records, we see SMF30USO{Offset to zEDC usage
statistics Section} and the, SMF30USL{Length of zEDC usage statistics
Section} containing data.
We do not see the SMF30USN{Number of zEDC usage statistics sections} having
data. This has been noticed since upgrading from a z14 to a z15 processor.
Has anyone else seen anything like this in their environment running MFT 8.0
or Connect Direct ?
Kenneth J. Kripke
3433 Plumtree Drive
Apt. K
Ellicott City, MD. 21042
Phones:
Land: 410-696-2307
Cell:443-851-1237
k.kri...@comcast.net Preferred
kennethkri...@gmail.com
--
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
--
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: Z15 zedc compression and CONNECT DIRECT, MFT compression
It is very common for SMF "Triplets" of Offset, Length, and Count
to populate the OFFSET, but to not populate the Count for segments
that do not exist in the record. And there can be more than one
triplets with that same OFFSET populated but with Counts zero.
It is also common to see segments that are present with
OFFSET and COUNT populated but with the LENGTH zero,
which means you have to go to OFFSET and INPUT the count field to
process those segments.
Barry
Herbert W Barry Merrill, PHD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
214 351 1966
ad...@mxg.com for business questions
supp...@mxg.com for technical questions
ba...@mxg.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Jousma, David
Sent: Wednesday, December 9, 2020 12:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Z15 zedc compression and CONNECT DIRECT, MFT compression
If you are using MXG with SAS, its likely you might need an update there?
_
Dave Jousma
AVP | Director, Technology 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
Kenneth J. Kripke
Sent: Wednesday, December 9, 2020 12:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Z15 zedc compression and CONNECT DIRECT, MFT compression
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or
unexpected emails**
Hello;
We have upgraded from a Z14 to Z15 processor, and, have experienced
something curious regarding the SMF TYPE 30 section being generated for
Connect Direct as well as Tibco's MFT 8.0 file transfer products.
Both products are enabled to use ZEDC compression, but, when generating SAS
reports from SMF type 30 records, we see SMF30USO{Offset to zEDC usage
statistics Section} and the, SMF30USL{Length of zEDC usage statistics
Section} containing data.
We do not see the SMF30USN{Number of zEDC usage statistics sections} having
data. This has been noticed since upgrading from a z14 to a z15 processor.
Has anyone else seen anything like this in their environment running MFT 8.0
or Connect Direct ?
Kenneth J. Kripke
3433 Plumtree Drive
Apt. K
Ellicott City, MD. 21042
Phones:
Land: 410-696-2307
Cell:443-851-1237
k.kri...@comcast.net Preferred
kennethkri...@gmail.com
--
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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining required z/series hardware level - REVISED
Tachyon Web page says last updated 05/29/2010 11:06:28 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, December 9, 2020 4:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Determining required z/series hardware level - REVISED On Wed, 9 Dec 2020 at 10:53, Charles Mills wrote: > > I have been thinking about this. It is a daunting project. I once set out to > develop a simple list of opcodes with their required minimum hardware level. > I wanted to be able to answer questions of the form "management wants this > product to be able to run on a z9. Can I use AHI?" In fact I think I asked > for help on this list, and promised to share any results. I abandoned the > effort! I decided it was easier just to code AHI and assemble with ZS-5 or > whatever and see if I got an error. That list is obviously just one > component of your product. There has been a list at http://www.tachyonsoft.com/inst390o.htm for many years. I'm not at all sure it's maintained these days, but I use it frequently as a quick reference. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How test correct procstep RC with JCL IF?
I want to have a PROC //MYPROC PROC PRM1=,PRM2= //STEP1 EXEC PGM= etc. // IF (STEP1.RC = 4) THEN //STEP2 EXEC PGM= etc. // ENDIF And then in a job execute the PROC several times: //X EXEC MYPROC,PRM1=A,PRM2=B //Y EXEC MYPROC,PRM1=C,PRM2=D Question: Will the IF in the proc test the RC for the STEP1 in that execution of the proc? Or some other execution of the PROC, perhaps the first? Is there a way to make it test "its own" STEP1.RC? Something kind of like (*.STEP1.RC = 4) ? I don't see any examples in the JCL manual of IF statements inside a PROC. Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security and z/OS open source tools
W dniu 09.12.2020 o 22:58, Frank Swarbrick pisze: I have downloaded and installed in my personal z/OS Unix directory curl and a few other z/OpenSource tools from Rocket Software. I have asked my z/OS security guy if we can go ahead and have our systems group (outsourced to IBM zCloud) "officially" install them. He came back with the following: "My question is how do we approve, track and secure the open source code we are putting on z/OS?" Does anyone have suggestions on answering this concern? Timothy gave you good answer. However I dare to share my comments: 1. It is NOT matter of open-source or closed source. 2. There is difference between freeware and open source. Freeware can be closed source and open source can be licensed. And licensed is usually paid, but it need not to be. 3. IMHO the most important is the support. It need not be contractual (usually paid) formal support, but as with many other tools (Firefox, java in the old years). CBT tools are not supported and usually the update process is slow or none. However tools from one-man-band-company are also "suspected" in terms of support. 4. Is the tool a part of airplane or just bicycle? In other words how crucial for the production it is. Some tools are very useful, but lack of them would not stop production. It would make things harder. 5. Security issues. Many "insecure products" provide no risk at all when used in controlled, closed, isolated environment. It is important to understand the vulnerabilities. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security and z/OS open source tools
On 09/12/2020 22:25, Paul Gilmartin wrote: On Wed, 9 Dec 2020 21:58:34 +, Frank Swarbrick wrote: I have downloaded and installed in my personal z/OS Unix directory curl and a few other z/OpenSource tools from Rocket Software. I have asked my z/OS security guy if we can go ahead and have our systems group (outsourced to IBM zCloud) "officially" install them. He came back with the following: "My question is how do we approve, track and secure the open source code we are putting on z/OS?" Note that curl issued multiple security advisories today, including: https://curl.se/mail/archive-2020-12/0007.html How long does it take Rocket to catch up? Have Rocket's patches been merged into the curl base on github? Does anyone have suggestions on answering this concern? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Please see the Rocket forum about how they maintain and distribute updates to the tools and using miniconda as the deployment tool. Internally Rocket have done a lot of work to speed up delivery of new releases and CVE fixes. https://community.rocketsoftware.com/home. Tony Sinfield, Rocket Software. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: does anyone recall any details about MVS/XA?
W dniu 09.12.2020 o 20:02, Paul Gilmartin pisze: On Wed, 9 Dec 2020 19:31:34 +0100, R.S. wrote: ... I perceived aversion to RECEIVE FROMNTS as UNIXphobia. Our product was not so large that DASD space was a concern. Can't please everyone. Gil, Don't kill messenger ;-) Was that statement hostile? (But smiley noted.) And thanks. Just a joke. How do you call it? Lost in translation? Seriously: it wasn't hostile. Yes, it is possible to IPL from network, it has been possible since z990 or z9. ... Of course the server is not included, so it is up to you to set up some ftp/sftp/ftps server and disk space, and Internet connectivity.And power supply... And, especially, configure IP address and path in (HMC?) bootstrap loader. How much driver system needs to be installed to support RECEIVE ORDER? (Is that the next step? Well, I'm not sure I understand it correctly, however installation process is the following: z/OS - prepare IOCDS (how? using assembler macros!) to make your configuration compatible with IODF delivered with Driver System. - IPL from network. Note, it is NOT z/OS, it is standalone utility (dss) to restore three disk volume images. - IPL Driving System from restored DASD. - logon to z/OS Driving System and work as on regular z/OS - run ServerPac Installation Dialog. z/VM - IPL from network - this time some z/VM image will start. - press ENTER, ENTER, ENTER... - like in Windows ;-) z/Linux similar to the above z/VSE I have no idea z/TPF I have no idea ... zLinux installation is IPL-able >from network. ZZSA is IPL-able from network. ZZSA? AZERTY keyboard? This is standalone utility from Jan Jaeger. It may be last resort when you cannot IPL your z/OS due to syntax errors in PARMLIB or IPLPARM. Regards -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
