Re: Does z/OS V1R13 CSF support TLS v1.2?
OA39422: NEW FUNCTION - TLS V1.2 SUPPORT in case anyone else is interested. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian France Sent: Friday, November 21, 2014 1:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Does z/OS V1R13 CSF support TLS v1.2? For z/OS 1.13 there's a PTF. Sorry off hand I do not know it. On 11/21/2014 3:43 PM, Charles Mills wrote: I call gsk_attribute_set_enum(env_handle, GSK_PROTOCOL_TLSV1_2, GSK_PROTOCOL_TLSV1_2_ON) and get RC 701 Attribute identifier is not valid. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES/328X Installation Manual
Thanks, I got it.. Jose On Nov 19, 2014, at 2:42 PM, George Young gmyo...@windstream.net wrote: On 11/19/2014 2:21 AM, Jose Munoz wrote: Dear all, Who can send me electronic copy for 5785-BAZ JES/328X Print Facility Program Description and Operators Manual , SH20-7174. I cannot find on internet. Regards Jose Munoz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN If you go to the IBM Publications Center and search for SH20-7174 you'll find a copy you can download. http://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss George -- 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: Why is the System Data Sets book no longer deemed useful?
When did it last exist? I have V1R10 docs here and I don't see it. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Friday, November 21, 2014 11:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Why is the System Data Sets book no longer deemed useful? As the System Data Set Definition book hasn't been published in rather a long time ... Why is this? Isn't this a valuable book for those new to z/OS (and for us old guys with shrinking memories as well)? IBM makes us believe how serious they take it to get new people aboard on z/OS. Good, extensive documentation has aways be one strength of z/OS (and it predecesors). IBM should stop (silently) droping documentation. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch Msgid Profile
We occasionally see this message: IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED I cannot find a current instance of this message in my system, but basically it means that the purported SAF userid is not defined to TSO--I guess either installed security product or UADS. The explanation of this message does not state how or where the 'default' comes from. The message is issued by IKJEFT01. I imagine that a newly defined vanilla TSO userid would contain the defaults referred to by IKJ56644I. I don't know of any programmatic way to influence the default definition. If a valid userid does exist, the associated attributes are used. I especially don't know why anyone would actually choose *not* to see WTOs with msgid, but that's the default. This design may hark back to the advent of TSO, when it was the only interactive mechanism for the mainframe OS. In those days TSO was just as likely--maybe more so--to be used by clerical staff as by programmers. Messages and their ids would have been noise to many users. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Friday, November 21, 2014 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Batch Msgid Profile IKJEFF10? snip Is there a Default table or exit that is/can be set for all batch submits, so it would work without entering the 'PROF MSGID WTPMSG'? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why is the System Data Sets book no longer deemed useful?
When did it last exist? I have V1R10 docs here and I don't see it. I found one in the z/OS V1.1 bookshelf -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How declare in C++ a constant in an assembler module?
Until today, PL/1 does not support 64 bit (addressing mode), so this discussion comes too early. As already mentioned, the types that have explicit bit numbers like BIN FIXED (15), BIN FIXED (31) or BIN FIXED (63) - which exists already - and the UNSIGNED variants, as - for example - BIN FIXED (64) UNSIGNED, have no problem. What really would be a problem for a 64 bit exploiting PL/1 compiler: all PTR variables would suddenly need 8 bytes, and that would break most of the current structure definitions etc., because much code implicitely assumes that the pointers need 4 bytes. This is exactly the same problem that we faced when we first migrated our insurance math package to a 64 bit Linux. Another problem, when doing this migration, was, that all long declarations (which were 4 bytes until this time) had to be changed to int, because long now was 8 bytes, too, which was a big problem for us. This problem would not have occured with the PL/1 notation BIN FIXED (31). So I am not sure, what is better in this case. (similar problem some 20 years ago, when int was 16 bit on PC platform, so we had to code long back then, to get 31 bit on all platforms ... PCs, Unix, z/OS ... which was OS/390 then). Kind regards Bernd Am 20.11.2014 18:26, schrieb Paul Gilmartin: On Thu, 20 Nov 2014 11:32:22 -0500, Tony Harminc wrote: Why would you have to/want to change the declarations? Specify the size needed for your application data, and let the compiler figure out what to do internally. Of course if you're doing something bizarre like UNSPECing a pointer value into a FIXED BIN (31)... Especially if it's a pointer to above-the-bar storage. Are there separate 24-bit, 31-bit, and 64-bit pointer types? -- 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
Re: Binder SYSPRINT wrap?
Gil mentioned the DATA SET SUMMARY section. I presume his use involved the file system. For a data set, the lines in that section would not come close to reaching column 84. For example, DDNAMECONCAT FILE IDENTIFICATION LPALIB 01 SYS1.LPALIB SYSOBJS 02 TESTUSER.OBJS I would guess that many who read the append did not realize that the original post related to presentation of a long path name. I know that I did not. Regardless, for whatever reason, when the binder was developed going on 25 years ago someone implemented put 64 columns of path name info per line. Maybe they thought that was a reasonable amount, maybe they wanted a power of two; I have no idea. This has apparently not been an issue to anyone. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Binder SYSPRINT wrap?
In caajsdjifcetyukih8nywc22e9r5epqlvwdy1tm3uaiujsmk...@mail.gmail.com, on 11/21/2014 at 02:37 PM, John McKown john.archie.mck...@gmail.com said: I think gil has more of a UNIX background. When you are used to truly long lines, the z/OS use of 121 or 132 byte print lines can be a real PITA. Yeah, the 1443 is too new to consider 145[1], much less 205. [1] cc included. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Binder SYSPRINT wrap?
So it WASN'T done just to annoy Gil? Darn! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Saturday, November 22, 2014 4:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Binder SYSPRINT wrap? Gil mentioned the DATA SET SUMMARY section. I presume his use involved the file system. For a data set, the lines in that section would not come close to reaching column 84. For example, DDNAMECONCAT FILE IDENTIFICATION LPALIB 01 SYS1.LPALIB SYSOBJS 02 TESTUSER.OBJS I would guess that many who read the append did not realize that the original post related to presentation of a long path name. I know that I did not. Regardless, for whatever reason, when the binder was developed going on 25 years ago someone implemented put 64 columns of path name info per line. Maybe they thought that was a reasonable amount, maybe they wanted a power of two; I have no idea. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
