Re: Unreadable code (Was: Concurrent Server Task Dispatch issuemultitasking issue)
Interesting stuff! Thank you Ed! I did not realize the OOO execution capabilities were as smart as your example suggests, and try to write code that runs free of charge whenever possible. But I will have to give that one a whirl. And if in your samples, Fields 1-4 happened to be consecutive fullwords, then you could likely reduce the number of storage fetches to just one and storage updates also to just one, but you would still need the 4 increments. I have steered clear of ASI instruction in the past because of possible interlock overhead when I did not need things serialized, but that too may be less of an issue these days. Mike From: IBM Mainframe Discussion List on behalf of David Crayford Sent: Sunday, January 13, 2019 11:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue) On 14/01/2019 6:06 am, Ed Jaffe wrote: > On 1/13/2019 4:08 AM, David Crayford wrote: >> On 13/01/2019 7:06 pm, Tony Thigpen wrote: >>> I have seen some reports that current C compilers, which understand >>> the z-hardware pipeline, can actually produce object that is faster >>> running than an assembler. Mainly because no sane assembler >>> programmer would produce great pipe-line code because it would be >>> un-maintanable. >>> >> It's well established that that's been true for a well over a decade >> now. Not just C but all compilers including COBOL which got a new >> optimizer a few releases back. > > > Far, far less true now than it used to be. > Good to hear. The best optimization is done in hardware where you don't have to recompile. Followed by a JIT. > Back in the old days, things ran a lot faster if you interleaved > unrelated things in an "unfriendly" way. For example, this code fragment: > > |LGF R0,Field1 Increment Field1 > |AGHI R0,1(same) > |ST R0,Field1 (same) > |LGF R0,Field2 Increment Field2 > |AGHI R0,1(same) > |ST R0,Field2 (same) > |LGF R0,Field3 Increment Field3 > |AGHI R0,1(same) > |ST R0,Field3 (same) > |LGF R0,Field4 Increment Field4 > |AGHI R0,1(same) > |ST R0,Field4 (same) > > ran much faster when coded this way (which is not how a programmer > would usually write things): > > |LGF R0,Field1 Increment Field1 > |LGF R1,Field2 Increment Field2 > |LGF R2,Field3 Increment Field3 > |LGF R3,Field4 Increment Field4 > |AGHI R0,1(same) > |AGHI R1,1(same) > |AGHI R2,1(same) > |AGHI R3,1(same) > |ST R0,Field1 (same) > |ST R1,Field2 (same) > |ST R2,Field3 (same) > |ST R3,Field5 (same) > > But once OOO execution came on the scene with z196, you could get the > same enhanced performance from this easy-to-code and easy-to-read > version: > > |LGF R0,Field1 Increment Field1 > |AGHI R0,1(same) > |ST R0,Field1 (same) > |LGF R1,Field2 Increment Field2 > |AGHI R1,1(same) > |ST R1,Field2 (same) > |LGF R2,Field3 Increment Field3 > |AGHI R2,1(same) > |ST R2,Field3 (same) > |LGF R3,Field4 Increment Field4 > |AGHI R3,1(same) > |ST R3,Field4 (same) > > These days, many performance improvements are realized by the compiler > using newer instructions that replace older ones. For example, on z10 > and higher, this very same code can be replaced with: > > |ASI Field1,1Increment Field1 > |ASI Field2,1Increment Field1 > |ASI Field3,1Increment Field1 > |ASI Field4,1Increment Field1 > IIRC, the interleaved instruction scheduling was to mitigate the AGI problem? In my experienced the two optimizations that make the most difference are function inlining and loop unrolling. I've taken to defining functions in header files to take advantage of both (we don't use IPA). > Of course, an HLASM programmer can do exactly the same thing. But > changing old code to use new instructions requires > relatively-expensive programmer resources whereas simply recompiling > programs targeting a new machine is a relatively-inexpensive proposition. > > I've noticed (depending on compiler options) the C optimizer is starting to use vector instructions. They can be a bit hairy even for experienced assembler programmers. Best to leave that to a compiler IMO. Instead of using a SRST instruction strlen() generates the following: VLBB v0,str(r6,r9,0),2 LCBB r7,str(r6,r9,0),2 LR r0,r6 ALR r6,r7 VFENEB v0,v0,v0,b'0010' VLGVBr2,v0,7 CLRJHr7,r2,@2L33 VLBB v0,str(r6,r9,0),2 LCBB r7,str(r6,r9,0),2 LR r0,r6 ALR r6,r7 VFENEB v0,v0,v0,b'0010' VLGVBr2,v0,7 CLRJHr7,r2,@2L33 VLBB v0,str(r6,r9,0),2 LCBB r7,str(r6,r9,0
Re: zos program to supply web based client
No, single server getting the next available slot to schedule an available time. I have a slot of studying to do now while I track down all of your suggestions. Thanks again, Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
On 14/01/2019 6:06 am, Ed Jaffe wrote: On 1/13/2019 4:08 AM, David Crayford wrote: On 13/01/2019 7:06 pm, Tony Thigpen wrote: I have seen some reports that current C compilers, which understand the z-hardware pipeline, can actually produce object that is faster running than an assembler. Mainly because no sane assembler programmer would produce great pipe-line code because it would be un-maintanable. It's well established that that's been true for a well over a decade now. Not just C but all compilers including COBOL which got a new optimizer a few releases back. Far, far less true now than it used to be. Good to hear. The best optimization is done in hardware where you don't have to recompile. Followed by a JIT. Back in the old days, things ran a lot faster if you interleaved unrelated things in an "unfriendly" way. For example, this code fragment: | LGF R0,Field1 Increment Field1 | AGHI R0,1 (same) | ST R0,Field1 (same) | LGF R0,Field2 Increment Field2 | AGHI R0,1 (same) | ST R0,Field2 (same) | LGF R0,Field3 Increment Field3 | AGHI R0,1 (same) | ST R0,Field3 (same) | LGF R0,Field4 Increment Field4 | AGHI R0,1 (same) | ST R0,Field4 (same) ran much faster when coded this way (which is not how a programmer would usually write things): | LGF R0,Field1 Increment Field1 | LGF R1,Field2 Increment Field2 | LGF R2,Field3 Increment Field3 | LGF R3,Field4 Increment Field4 | AGHI R0,1 (same) | AGHI R1,1 (same) | AGHI R2,1 (same) | AGHI R3,1 (same) | ST R0,Field1 (same) | ST R1,Field2 (same) | ST R2,Field3 (same) | ST R3,Field5 (same) But once OOO execution came on the scene with z196, you could get the same enhanced performance from this easy-to-code and easy-to-read version: | LGF R0,Field1 Increment Field1 | AGHI R0,1 (same) | ST R0,Field1 (same) | LGF R1,Field2 Increment Field2 | AGHI R1,1 (same) | ST R1,Field2 (same) | LGF R2,Field3 Increment Field3 | AGHI R2,1 (same) | ST R2,Field3 (same) | LGF R3,Field4 Increment Field4 | AGHI R3,1 (same) | ST R3,Field4 (same) These days, many performance improvements are realized by the compiler using newer instructions that replace older ones. For example, on z10 and higher, this very same code can be replaced with: | ASI Field1,1 Increment Field1 | ASI Field2,1 Increment Field1 | ASI Field3,1 Increment Field1 | ASI Field4,1 Increment Field1 IIRC, the interleaved instruction scheduling was to mitigate the AGI problem? In my experienced the two optimizations that make the most difference are function inlining and loop unrolling. I've taken to defining functions in header files to take advantage of both (we don't use IPA). Of course, an HLASM programmer can do exactly the same thing. But changing old code to use new instructions requires relatively-expensive programmer resources whereas simply recompiling programs targeting a new machine is a relatively-inexpensive proposition. I've noticed (depending on compiler options) the C optimizer is starting to use vector instructions. They can be a bit hairy even for experienced assembler programmers. Best to leave that to a compiler IMO. Instead of using a SRST instruction strlen() generates the following: VLBB v0,str(r6,r9,0),2 LCBB r7,str(r6,r9,0),2 LR r0,r6 ALR r6,r7 VFENEB v0,v0,v0,b'0010' VLGVB r2,v0,7 CLRJH r7,r2,@2L33 VLBB v0,str(r6,r9,0),2 LCBB r7,str(r6,r9,0),2 LR r0,r6 ALR r6,r7 VFENEB v0,v0,v0,b'0010' VLGVB r2,v0,7 CLRJH r7,r2,@2L33 VLBB v0,str(r6,r9,0),2 LCBB r7,str(r6,r9,0),2 LR r0,r6 VFENEB v0,v0,v0,b'0010' ALR r6,r7 VLGVB r2,v0,7 CLRJH r7,r2,@2L33 VLBB v0,str(r6,r9,0),2 LCBB r7,str(r6,r9,0),2 LR r0,r6 ALR r6,r7 VFENEB v0,v0,v0,b'0010' VLGVB r2,v0,7 CLRJNH r7,r2,@2L25 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Physical tape addition to RMM
Hi Good evening Does anyone have a procedure or link which helps me to understand to add the volser of Physical tapes in RMM ? Regards Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zos program to supply web based client
Brian Westerman wrote: >The don't have CICS, that would have made this almost easy. Yes. >z/OS, Adabas, Com-Plete on the mainframe, the open system server >is Windows Server 2018, the application is looking for the "next" >available date to schedule their task, but the "owner" of that >schedule is on the mainframe. The "old" application would jsut >go to Adabas, grab the next available empty schedule slot, and >mark it used. The "new" application still needs to get that >schedule "slot" from the mainframe, but does everything else on >it's own. So they need to ask the mainframe to run a task that >will go to Adabas, get the next avaiable slot, mark it used, and >pass it back to the Windows server. OK. In the IBM product portfolio, z/OS Connect Enterprise Edition or, if direct to ADABAS, Data Virtualization Manager for z/OS would likely be the preferred, elegant approaches. However, if you want to cobble something together without too much effort as a "one off," and with something your customer already has licensed, I would look at the z/OS Management Facility and its REST interface for jobs. Details are available here (z/OS 2.3 information): https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.izua700/IZUHPINFO_API_RESTJOBS.htm The Windows Server would submit a z/OS job using this REST interface, and that z/OS job would then execute whatever program logic and ADABAS database update(s) are required, then return the result (the schedule slot). Probably what you'd do is use the z/OSMF REST interface to submit a job (and have the client check to make sure the HTTP return code is one of the return codes that indicates z/OS received the request), then use the z/OS Client Web Enablement Toolkit so that z/OS can return the result to the Windows Server (and can invoke a REST interface on the Windows Server available for that purpose). I've seen people suggest FTP and ssh paths, and they involve the same basic principle (submit a job, get a result), but I think those paths are less future proof and would involve some more work for error handling. I also have greater security concerns with those paths and think the necessary work to make these REST interfaces secure would be less onerous. Sockets are rather hard. There are hacky ways for z/OS to take action after another system places a file on a network drive (NFS) shared between that system and z/OS, but I don't like idea at least in this case. The Windows Server could have a 3270 emulator installed, such as IBM Personal Communications, which runs a macro that then makes its request and receives its response over an encrypted TN3270E connection to the "normal" 3270 application for getting a schedule slot. That's not my favorite path either. Another possible approach is to use Software AG's HTTP Server that's embedded in its Com-plete transaction processor. It's pretty basic, but it does support CGI. (I suspect Software AG was inspired by CICS Web Support.) I don't think Com-plete's HTTP Server supports HTTPS on its own, but fortunately you can (and should) use z/OS's AT-TLS to solve that problem. Here's some information on how you would set up AT-TLS with CICS Transaction Server if CICS is using HTTP (not HTTPS): https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.5.0/security/web/dfht3_attls.html The AT-TLS setup with Com-plete's HTTP Server should be quite similar. Alternatively, you could set up an IPSec tunnel between the Windows machine and z/OS. One problem with a Com-plete-based approach is that it won't work for your other customers that don't have Com-plete. It also wasn't inherently designed for application-to-application integration (as REST interfaces are), although it can be used that way in a pinch. I would think about how to avoid "double booking" and other such issues. Do they need transaction scope across both systems? Timothy Sipples IT Architect Executive, 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
On 1/13/2019 4:08 AM, David Crayford wrote: On 13/01/2019 7:06 pm, Tony Thigpen wrote: I have seen some reports that current C compilers, which understand the z-hardware pipeline, can actually produce object that is faster running than an assembler. Mainly because no sane assembler programmer would produce great pipe-line code because it would be un-maintanable. It's well established that that's been true for a well over a decade now. Not just C but all compilers including COBOL which got a new optimizer a few releases back. Far, far less true now than it used to be. Back in the old days, things ran a lot faster if you interleaved unrelated things in an "unfriendly" way. For example, this code fragment: | LGF R0,Field1 Increment Field1 | AGHI R0,1 (same) | ST R0,Field1 (same) | LGF R0,Field2 Increment Field2 | AGHI R0,1 (same) | ST R0,Field2 (same) | LGF R0,Field3 Increment Field3 | AGHI R0,1 (same) | ST R0,Field3 (same) | LGF R0,Field4 Increment Field4 | AGHI R0,1 (same) | ST R0,Field4 (same) ran much faster when coded this way (which is not how a programmer would usually write things): | LGF R0,Field1 Increment Field1 | LGF R1,Field2 Increment Field2 | LGF R2,Field3 Increment Field3 | LGF R3,Field4 Increment Field4 | AGHI R0,1 (same) | AGHI R1,1 (same) | AGHI R2,1 (same) | AGHI R3,1 (same) | ST R0,Field1 (same) | ST R1,Field2 (same) | ST R2,Field3 (same) | ST R3,Field5 (same) But once OOO execution came on the scene with z196, you could get the same enhanced performance from this easy-to-code and easy-to-read version: | LGF R0,Field1 Increment Field1 | AGHI R0,1 (same) | ST R0,Field1 (same) | LGF R1,Field2 Increment Field2 | AGHI R1,1 (same) | ST R1,Field2 (same) | LGF R2,Field3 Increment Field3 | AGHI R2,1 (same) | ST R2,Field3 (same) | LGF R3,Field4 Increment Field4 | AGHI R3,1 (same) | ST R3,Field4 (same) These days, many performance improvements are realized by the compiler using newer instructions that replace older ones. For example, on z10 and higher, this very same code can be replaced with: | ASI Field1,1 Increment Field1 | ASI Field2,1 Increment Field1 | ASI Field3,1 Increment Field1 | ASI Field4,1 Increment Field1 Of course, an HLASM programmer can do exactly the same thing. But changing old code to use new instructions requires relatively-expensive programmer resources whereas simply recompiling programs targeting a new machine is a relatively-inexpensive proposition. -- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
Steve, Agree, I learned Assembler first then self-taught in C ... Only played with Java, I actually like python... Scott On Sun, Jan 13, 2019 at 4:06 PM Steve Smith wrote: > I entirely agree. The syntax for mapping C variables to in-line assembler > code is hideous and error-prone (at least for me). Conversely, the linkage > for an assembler subroutine is very standard. That's the way to go if the > code requires more than a couple of variables. > > sas > > On Sun, Jan 13, 2019 at 7:08 AM David Crayford > wrote: > > > ... > > > > > I still maintain that some code > > is still better written in assembler. I'm a C/C++ programmer these days > > but for some subroutines an assembler program is much easier to > > understand then lots of inlined __asm() blocks. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
I entirely agree. The syntax for mapping C variables to in-line assembler code is hideous and error-prone (at least for me). Conversely, the linkage for an assembler subroutine is very standard. That's the way to go if the code requires more than a couple of variables. sas On Sun, Jan 13, 2019 at 7:08 AM David Crayford wrote: > ... > I still maintain that some code > is still better written in assembler. I'm a C/C++ programmer these days > but for some subroutines an assembler program is much easier to > understand then lots of inlined __asm() blocks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.12 question
One product I discussed here last year. There was a change in TSO/E that caused StarTool to fail from the get-go. (Same problem with CBT PDS command.) For whatever reason the 'fix' was a whole new release of the product. I think there was some misunderstanding in our pro forma query to Microfocus, the new owner of Serena. In any case we were caught off guard. The other product was BMC Discovery, which was quite old and the object of some benign neglect. Not that benign actually. It would not run at all. Still working on a new release. The point of my emphatic posts is that while you may get away with forging ahead and 'fixing forward', the prudent course is to seek and follow vendors' advice whether or not it's strictly necessary. My ROT is which outcome you'd rather have to explain to the boss: some zealous over-prep or a hat-in-hand interruption to the published upgrade schedule. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Westerman Sent: Sunday, January 13, 2019 12:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: z/OS 1.12 question That's a pretty odd thing to happen from 2.1 to 2.3. What products were involved? I can see if the product had some ties into JES2 and you had to reassemble or relink the interface, but that can happen just by adding maintenance to any system. It's really odd for almost any vendor product to be tied into a specific OS especially when they are quite so close in release. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
On Sat, 12 Jan 2019, 23:43 Paul Gilmartin, < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > > More concisely: > TRUE = 1 > FALSE = 0 > > These are in he Rexx Standard; you may rely on them. Nonetheless, you > may choose to assign those mnemonics for clarity. > Yes, in the standard. It was a long time ago. I can't remember now whether I didn't know it at the time, or whether I was dealing with a dodgy implementation on one of the platforms it might run on. > I consider > if flag = TRUE ... > and > if flag = FALSE ... > and > if A == B then flag = TRUE; else flag = false > > ... (which I've seen used) execrable expansions of > if flag ... > or > if \flag ... > or > flag = ( A == B ) /* Superfluous parentheses may enhance clarity. ) > > )you might as well code: > if flag = TRUE = TRUE = TRUE ... > Yes, execrable, and a sure sign the programmer needs a basic course in boolean :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Fwd: What's ahead for 2019 by Trevor Eddolls
https://it.toolbox.com/blogs/trevoreddolls/whats-ahead-for-2019-011319 Thanks, Mark T. Regan, K8MTR CTO1 USNR-Retired, 1969-1991 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
On 13/01/2019 7:06 pm, Tony Thigpen wrote: I have seen some reports that current C compilers, which understand the z-hardware pipeline, can actually produce object that is faster running than an assembler. Mainly because no sane assembler programmer would produce great pipe-line code because it would be un-maintanable. It's well established that that's been true for a well over a decade now. Not just C but all compilers including COBOL which got a new optimizer a few releases back. The game changer for systems programming was Metal/C which can be used for AR mode stuff using __far pointers. I still maintain that some code is still better written in assembler. I'm a C/C++ programmer these days but for some subroutines an assembler program is much easier to understand then lots of inlined __asm() blocks. I am an assembler programmer, not a C programmer, so I view the reports with some speciesism. Tony Thigpen scott Ford wrote on 1/12/19 1:33 PM: I am speaking in terms of development cycle. On Sat, Jan 12, 2019 at 1:32 PM scott Ford wrote: David and Zman, Both good points, C is certainly faster than Assembler or maybe PL/S On Sat, Jan 12, 2019 at 2:17 AM David Crayford wrote: On 12/01/2019 4:08 am, Seymour J Metz wrote: despite being used frequently for the purpose, it's really not particularly suited for writing operating systems LOL! That's absurd! C has been ported to just about every architecture worth mentioning and is well suited to low-level programming. It's also incredibly efficient and has a mature and well established tool chain for debugging, profiling, code correctness etc. What do you consider a good language for writing operating systems? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Scott Ford IDMWORKS z/OS Development -- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
I have seen some reports that current C compilers, which understand the z-hardware pipeline, can actually produce object that is faster running than an assembler. Mainly because no sane assembler programmer would produce great pipe-line code because it would be un-maintanable. I am an assembler programmer, not a C programmer, so I view the reports with some speciesism. Tony Thigpen scott Ford wrote on 1/12/19 1:33 PM: I am speaking in terms of development cycle. On Sat, Jan 12, 2019 at 1:32 PM scott Ford wrote: David and Zman, Both good points, C is certainly faster than Assembler or maybe PL/S On Sat, Jan 12, 2019 at 2:17 AM David Crayford wrote: On 12/01/2019 4:08 am, Seymour J Metz wrote: despite being used frequently for the purpose, it's really not particularly suited for writing operating systems LOL! That's absurd! C has been ported to just about every architecture worth mentioning and is well suited to low-level programming. It's also incredibly efficient and has a mature and well established tool chain for debugging, profiling, code correctness etc. What do you consider a good language for writing operating systems? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: zos program to supply web based client
Woohoo, I've (probably) helped one person.. I'm a community champion! – Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: 13 January 2019 08:27 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: zos program to supply web based client Now those are really cool. I had never heard of them but I am thankful that you pointed me to them. Thanks, Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zos program to supply web based client
Now those are really cool. I had never heard of them but I am thankful that you pointed me to them. Thanks, Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.12 question
That's a pretty odd thing to happen from 2.1 to 2.3. What products were involved? I can see if the product had some ties into JES2 and you had to reassemble or relink the interface, but that can happen just by adding maintenance to any system. It's really odd for almost any vendor product to be tied into a specific OS especially when they are quite so close in release. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Next meeting of the GSE UK Security Working Group - 7th February
Ladies and Gentlemen, Happy New Year to you. The next meeting of the GSE UK Security Working Group, will take place on Thursday 7th February 2019 at the new offices of RSM Partners in Bromsgrove, UK (a 40 minute drive from Birmingham Airport). You can access the full agenda from here > http://www.racf.gse.org.uk/content/content_download.php?agendaid=23 Highlights from the agenda include: * Using thin-client terminal emulation to secure 3270 access * How to improve your RACF testing to prevent production issues * Secure Engineering: How to develop authorised code without compromising z/OS system integrity * Securing IBM MQ for GDPR and Regulatory compliance * Network Security – don’t forget VTAM/SNA * Identity Management: Using the right tooling To register, please go to this link > http://www.racf.gse.org.uk/content/content_event_register.php?id=23 If you have a certification or you are studying, you can earn up to 7 CPEs for attending this event. We hope that you will be able to join us! Regards Mark Wilson and Jamie Pease -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
