Re: Open XL C++ debugging
On 2/2/23 02:42, Joseph Reichman wrote: Was looking at the compiler reference kind of small handful of options compared to pages and pages for XL C\C++ compiler option Haha! You're joking right? There's significantly more compiler options as it's a port of clang https://www.ibm.com/docs/en/SSUMVNF_1.1.0/pdf/Clang.pdf#page=219. One very important question when I looked at the Manuel doesn’t specify how to debug it How do you debug any C/C++ program in z/OS UNIX. You compile with the "-g" flag which creates DWARF debugging records and the use dbx to debug. The interesting thing about Open XL C++ is that it embeds debug information into the binary as opposed to creating a *.dbg side file. My advice to you use the XL C/C++ v2.4.1 web deliverable xlclang. I don't think you need to be on the bleeding edge of language standards :) -- 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: GETMAIN LOC=32
No. LA (and all LA variations) are modal, in that LA will not affect the high-half of the register, unless executing in AMODE 64. Anyway, what's the point of clearing registers unless or until you need to use them? sas On Wed, Feb 1, 2023 at 8:02 PM Paul Edwards wrote: > On Sun, 6 May 2018 18:34:35 -0500, Paul Edwards > wrote: > > Sorry for the necro ... > > >On Sun, 6 May 2018 16:11:57 -0700, Charles Mills > wrote: > > > >>2. A 31/32-bit program cannot count on the high > >> halves being zero in any event. There is no > >> guarantee that you are entered with the high > >> halves equal to zero, > > > >The 32-bit program can clear all registers with > >LMH if IBM can't guarantee high halves of 0. > >It can do that once at startup and the rest of > >the program doesn't need to change. > > I recently realized that I should be able to use "LA Rx,0" > to clear the high 32-bits of undefined registers. (a separate > LA for each register). > > This only uses S/370 instructions and future-proofs the > code for if IBM produces a machine with 128-bit or 256-bit > registers. > > I'm thinking undefined registers on program entry need to > be cleared with LA, and whenever you call a z/OS service, > any register documented as being trashed needs to be > cleared (with LA) on return. > > I think that is sufficient? > > BFN. Paul. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM websites have the slows
Thank you Kolusu and Wayne. Still slow without the -40 in the URL. Assuming problems must be local to something in my region. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sri h Kolusu Sent: Wednesday, February 1, 2023 7:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM websites have the slows Caution! This message was sent from outside your organization. >>Noticed over the past few days that my attempts to access >>https://www-40.ibm.com/ websites are frequently met with access attempt >>failed due to lack of response from server. Mike, It comes up right away for me. Can you just try IBM directly without -40 in the URL? https://www.ibm.com/ Thanks, Kolusu -- 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: GETMAIN LOC=32
On Sun, 6 May 2018 18:34:35 -0500, Paul Edwards wrote: Sorry for the necro ... >On Sun, 6 May 2018 16:11:57 -0700, Charles Mills wrote: > >>2. A 31/32-bit program cannot count on the high >> halves being zero in any event. There is no >> guarantee that you are entered with the high >> halves equal to zero, > >The 32-bit program can clear all registers with >LMH if IBM can't guarantee high halves of 0. >It can do that once at startup and the rest of >the program doesn't need to change. I recently realized that I should be able to use "LA Rx,0" to clear the high 32-bits of undefined registers. (a separate LA for each register). This only uses S/370 instructions and future-proofs the code for if IBM produces a machine with 128-bit or 256-bit registers. I'm thinking undefined registers on program entry need to be cleared with LA, and whenever you call a z/OS service, any register documented as being trashed needs to be cleared (with LA) on return. I think that is sufficient? BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM websites have the slows
>>Noticed over the past few days that my attempts to access >>https://www-40.ibm.com/ websites are frequently met with access attempt >>failed due to lack of response from server. Mike, It comes up right away for me. Can you just try IBM directly without -40 in the URL? https://www.ibm.com/ Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM websites have the slows
Not slow in Australia. This is unusual because our internet is third world quality. On Thu, Feb 2, 2023 at 7:09 AM Mike Hochee wrote: > Noticed over the past few days that my attempts to access > https://www-40.ibm.com/ websites are frequently met with access attempt > failed due to lack of response from server. > > Anyone know what's up with these IBM sites? Cloud migration possibly? JK > > Thanks, > Mike > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM websites have the slows
Noticed over the past few days that my attempts to access https://www-40.ibm.com/ websites are frequently met with access attempt failed due to lack of response from server. Anyone know what's up with these IBM sites? Cloud migration possibly? JK Thanks, Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Open XL C++ debugging
Was looking at the compiler reference kind of small handful of options compared to pages and pages for XL C\C++ compiler option One very important question when I looked at the Manuel doesn’t specify how to debug it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS
Classification: Confidential I strongly suggest setting up sysplex file sharing for OMVS. This is pretty straight forward. See the USS Planning guide. Your service mountpoints would then be hung off of a directory in the OMVS sysplex root (as opposed to the system root). HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Tuesday, January 31, 2023 1:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OMVS [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] I assume you're not zfs file sharing? I usually don't mount etc or dev unless I'm doing an upgrade, but if you're not sharing the /SERVICE/ filesystems then yes you need to create the mount points first - then remount them on the moved-to LPAR Carmen On 1/31/2023 12:56 PM, Steve Beaver wrote: > I need to move my SMPe from one LPAR to another. > > > > My concern are my MOUNTPOINTS. > > > > My current zFS is ETC with a mountpoint of > > > > /SERVICE/MVS1/etc > > > > Do I need to mount the MP and go create the > > > > /SERVICE/DEV1/etc > > > > Then UNMOUNT and MOUNT it again as /DEV1/etc > > > > > > Regards, > > > > > > Steve Beaver > > > > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Carmen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL // SET SYMBOL indirection
Or IBM knows something that you do not. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu] Sent: Tuesday, January 31, 2023 10:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCL // SET SYMBOL indirection On Wed, 1 Feb 2023 00:20:26 +, Farley, Peter wrote: >Not necessarily what you may want, but this works: > >//SYM1 SET SYM1=VALUE1 >//SYM2 SET SYM2=VALUE2 > >//TARGET SET TARGET= > >//RESULT SET RESULT= (and end up with being set to VALUE1 >and not SYM1) > >I know Gil will complain the observed JCL symbol behavior (assigning the value >of (a) previously defined symbol(s) to another symbol) is not documented (and >it is not), but it definitely works. I use this technique all the time in my >application testing JCL. > Yup. I have complained in these pages that every possible construct should either be documented as supported or result in a JCL error. In reply, Peter Relson has sneered at me, saying that I simply don't understand that constructs not documented but allowed should be regarded as for IBM internal use, comparable to undocumented macro parameters, or reserved for future extensions. JCL feels qualitatively different to me; undocumented constructs should at least result in warnings, or there should be a "PRO" option on the job statement, in the absence of which undocumented constructs should be reported as JCL errors. But, like you, I experiment: // SET SYM3=' ' /* No substitution -- it's documented. */ But: // SET Q='&' // SET SYM3= /* Substitution performed -- hardly documented. */ But there may be errors reported for using elsewhere, as in PARM=... These behaviors should be documented, but IBM doesn't care. -- 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
