Re: PoOP z/ARCH latest xx number
IBM has added a lot to HLASM in drips and drabs. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Steve Thompson Sent: Friday, September 20, 2024 2:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PoOP z/ARCH latest xx number Thank you all for the input. And, yes, just to be sure: I know the Jxx are extended mnemonics. And that reference to the HLASM Guide is good. It looks like I'm gonna get to play with conditional assembly again after many years. :) So I wanted to start boning up on instructions and new features in conditional assembly. Regards, Steve Thompson On 9/20/2024 12:42 PM, Ramsey Hallman wrote: > Appendix J - List of Extended Mnemonics > > On Fri, Sep 20, 2024 at 11:22 AM Joe Monk < > 05971158733e-dmarc-requ...@listserv.ua.edu> wrote: > >> I dont see any J mnemonics in the PoOP. >> https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf >> >> They are documented in the HLASM guide: >> https://publibz.boulder.ibm.com/epubs/pdf/asmr1021.pdf on page 67 >> >> They are also documented in the z/Arch Reference Summary: >> >> https://www.ibm.com/support/pages/sites/default/files/2021-05/SA22-7871-10.pdf >> on page 42 >> >> Joe >> >> On Fri, Sep 20, 2024 at 10:06 AM Wayne Driscoll < >> 05791921711d-dmarc-requ...@listserv.ua.edu> wrote: >> >>> Keep in mind that the Jxx instructions are "extended mnemonics" the >> actual >>> instructions are BRC (Branch Relative Conditional) and documented as >> that. >>> Wayne Driscoll >>> Broadcom MSD >>> All opinions are strictly my own >>> >>> On Fri, Sep 20, 2024 at 9:39 AM Ramsey Hallman < >>> 061e76a747b5-dmarc-requ...@listserv.ua.edu> wrote: >>> >>>> Steve, >>>> >>>> I believe the most recent is -13 ( Fourteenth Edition (May, 2022) - >> First >>>> Edition being 00). >>>> >>>> The Jump mnuemonics are definitely in that edition. >>>> >>>> Ramsey >>>> >>>> On Fri, Sep 20, 2024 at 9:27 AM Steve Thompson >> wrote: >>>>> I am trying to get an up to date copy of the PoOP and when I >>>>> check it for "J" instructions, I'm not finding them. >>>>> >>>>> Is this because those really only exist in HLASM? >>>>> >>>>> Certain instructions, I haven't used in years and wanted to make >>>>> sure they work, within reason (32 regs to 64 bit regs) as I >>>>> remembered. >>>>> -- >>>>> >>>>> Regards, >>>>> Steve Thompson >>>>> >>>>> >> -- >> 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 -- Regards, Steve Thompson -- 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: SMTP zOS in Python
One option is to use smtplib — SMTP protocol client.
Is it possible to use bpxwdyn from Python? If sou, allocate a SYSOUT dataset
and use essentially the same logic as the REXX code.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf of
Samuel Alejandro Díaz Chávez <054e78aaa484-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, September 18, 2024 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMTP zOS in Python
Good afternoon,
The question I have is a bit complex, but I do require your support.
I give a little context... I have a very large project in which I have to
“translate” REXX programs to python, and all executed via BATCH. As a first
program, I have to make one that, send some files via email. I already have the
whole program that does that, but I just need the SMTP sending part, but I have
no idea how to call the z/OS SMTP task or service with Python.
I understand that with the following structure, in REXX you can do it:
/* REXX */
LPAR = 'TEST LPAR '
SMTP.1 = 'HELO' MVSVAR('SYSNAME')
SMTP.2 = 'MAIL FROM:'
SMTP.3 = 'RCPT TO:'
SMTP.4 = 'DATA'
SMTP.5 = 'FROM:'
SMTP.6 = 'TO:'
SMTP.7 = 'SUBJECT:'LPAR'-DETAILS'
SMTP.8 = 'These are high priority alerts... '
"ALLOC F(SMTPOUT) SYSOUT(B) WRITER(SMTP)"
IF RC <> 0 THEN DO
SAY 'ERROR ALLOCATING SYSOUT FOR SMTP WRITER'
EXIT 12
END
"EXECIO * DISKW SMTPOUT (STEM SMTP. FINIS"
IF RC <> 0 THEN DO
So I ask for your support to know if there is a way to send an email through a
python program executed by BATCH and if you have any example, I would also
appreciate it very much.
--
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: Is z/OS FTP encrypted?
Assuming that everything is connected, you can use TSO TRANSMIT (XMIT) and RECEIVE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Bob Bridges <0587168ababf-dmarc-requ...@listserv.ua.edu> Sent: Monday, September 16, 2024 2:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Is z/OS FTP encrypted? Newbie question: I've just started work for a new client, and they (understandably) don't care for me using Win FTP to load up my REXX tools because it's not encrypted; the REXX execs aren't secret, but my ID and password should be. But once I've laboriously gotten a bunch of things uploaded using IND$FILE, what about moving them from one complex to another? Is FTP encrypted once I'm talking between two mainframes? --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* ...in February, United States coalition-building efforts are dealt a severe blow when France announces that it will not participate in the impending Iraq invasion, a decision that, in the words of Defense Secretary Donald Rumsfeld, "could seriously impair our ability to surrender". -Dave Barry’s 2003 Year in Review */ -- 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: So Long, and Thanks for All the Fish!
I'm sorry to hear it, but you've long since paid your dues and if that's what you want, you've earned it. Enjoy your retirement. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Cheryl Watson Sent: Sunday, September 8, 2024 4:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: So Long, and Thanks for All the Fish! Hi All, I’m about to remove my IBM-Main registration. At 80, with 60 years of mainframe behind me, it’s time for my retirement. Thank you all for your help, your support, and your friendship. I couldn’t have done it without you! All my best, Cheryl Watson == Cheryl Watson Walker, CEO Watson & Walker, Inc. Sarasota, FL USA http://www.watsonwalker.com/ Cell/Text: 941-266-6609 == -- 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: help with REXX code reading RACF LU function
For long lines, EXECIO and stream I/O are the preferred tools unless ISPF services are available. The say statement is intended for human-readable output. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Lizette Koehler Sent: Sunday, September 8, 2024 3:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: help with REXX code reading RACF LU function I am coding a REXX to read the output from LU userid I am working on learning IRRXUTIL but that will be a bit later I need to capture the name and installation date The Installation date can be long INSTALLATION-DATA=*** ** ** ** * My challenge is creating a one line entry for my results. It may go into excel later. Output keeps wrapping when I run REXX in batch with SAY commands Output will be USERID dlm NAME dlm Owner dlm Create Date dlm Last Logon dlm Installation-data Since the Installation- data can vary in length - the long lines wrap What is a good solution to create a 200 Lrecl output using SAY using ISIPF/REXX process Lizette -- 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: Happy 20th Birthday to zAAP
My reading i that it's a SAP, but we'll see when the documentation comes out. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of P H <04843e86df79-dmarc-requ...@listserv.ua.edu> Sent: Thursday, September 5, 2024 2:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Happy 20th Birthday to zAAP From what little information that is available, unlike the CP, IFP, ICF, IFL, zIIP and SAP processors the DPU is most probably an 'on-chip' function like AI, DFP, Compression, Crypto etc. Sent from Outlook for Android<https://aka.ms/AAb9ysg> From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Thursday, September 5, 2024 4:31:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Happy 20th Birthday to zAAP Data Processing Unit on Telum II. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of P H <04843e86df79-dmarc-requ...@listserv.ua.edu> Sent: Thursday, September 5, 2024 11:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Happy 20th Birthday to zAAP What is a DPU - Good Q. Never heard of it. For completeness, 2 of the PUs are also configured as IFPs (Integrated Firmware Processors). However, these are for 'system' use only. From: IBM Mainframe Discussion List on behalf of Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> Sent: 05 September 2024 15:12 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Happy 20th Birthday to zAAP What is DPU? -- Radoslaw Skorupka Lodz, Poland W dniu 05.09.2024 o 14:51, Bfishing pisze: > How cool is it that they, like so many other hardware features, were proven > virtually under z/VM first. I helped with some of the testing.. 20 years > ago now. > And I also like that IBM's CPU's can be configured in so many different > ways. GP, IFL, zIIP w/zAAP, SAP, CF, DPU... > What other architecture provides so many options? Yes, it is marketing, > but it would seem to have been done pretty smartly. > > -- 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 -- 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: Happy 20th Birthday to zAAP
Data Processing Unit on Telum II. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of P H <04843e86df79-dmarc-requ...@listserv.ua.edu> Sent: Thursday, September 5, 2024 11:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Happy 20th Birthday to zAAP What is a DPU - Good Q. Never heard of it. For completeness, 2 of the PUs are also configured as IFPs (Integrated Firmware Processors). However, these are for 'system' use only. From: IBM Mainframe Discussion List on behalf of Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> Sent: 05 September 2024 15:12 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Happy 20th Birthday to zAAP What is DPU? -- Radoslaw Skorupka Lodz, Poland W dniu 05.09.2024 o 14:51, Bfishing pisze: > How cool is it that they, like so many other hardware features, were proven > virtually under z/VM first. I helped with some of the testing.. 20 years > ago now. > And I also like that IBM's CPU's can be configured in so many different > ways. GP, IFL, zIIP w/zAAP, SAP, CF, DPU... > What other architecture provides so many options? Yes, it is marketing, > but it would seem to have been done pretty smartly. > > -- 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: [EXTERNAL] Upgrading z/OS vs. z/VM
Why? Isn't that what symbols are for? BTDT,GTTS -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Paul Schuster <06717d8b33e6-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, September 4, 2024 11:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Upgrading z/OS vs. z/VM Use different LOADxx member for each release you want to IPL. The LOADxx will point to the necessary parmlib members unique for that z/os level. I can IPL several different z/os levels quite easily. Everything else is the same. -- 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: Upgrading z/OS vs. z/VM
It has more to do with the shop than with the OS. I've quickly cloned and shuttled between LPARs when the system was laid out to support that. For z/OS tat mostly means IPLPARM and PARMLIB. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Tuesday, September 3, 2024 11:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Upgrading z/OS vs. z/VM I'm NOT trying to start a war here, just trying to grok whether I'm confused or not. I will make assertions below, any/all of which may be wrong, but that seems better than qualifying each with "I think..." etc. Upgrading z/VM versions has been pretty trivial for quite a while: point to a new CP module, reIPL. Upgrading z/OS is a lot harder. There's no way to just swap the OS itself, which means you need to clone the LPAR and then connect the user data volumes, with required catalog tinkering. And SPOOL needs to be backed up and restored (or contents lost). Is this really still true in 2024? -- 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: questions on HLL support of > 31-bit addressing
What wasn't clear was whether you and Mark were referring tothe same compilers; hence the question. Does GCC support AMODE64 on z/OS? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, September 3, 2024 10:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: questions on HLL support of > 31-bit addressing I think I was pretty clear that the FM in question was the Programmers Guide for each IBM supported compiler. Anyone using an ISV compiler is, of course, on their own. Peter From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Tuesday, September 3, 2024 8:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: questions on HLL support of > 31-bit addressing Which FM? In some cases compilers are available from multiple vendors. For older compilers, e.g., Ada, Pascal, it may be difficult to locate documentation, and there's no guaranty that information in DOC holds hs made its way into formal documentation. From: IBM Mainframe Discussion List on behalf of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Monday, September 2, 2024 11:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: questions on HLL support of > 31-bit addressing I hate to do it, but for the case of the current set of compilers, RTFM please. The C, COBOL V6 and PL/I Programmers Guide manual for each language clearly show the 64-bit support is there (LP32/LP64). I haven’t dealt with Fortran since Fortran II on an IBM 1620 in college, so I can’t say whether current Fortran does or not. As for when that support was added for each language, reading the list of changes per edition of the manuals should give you that information as well, though in recent year the “continuous update” philosophy means that support for a feature or capability doesn’t necessarily track with a manual edition or even necessarily with the compiler version or even its release level. Peter From: IBM Mainframe Discussion List On Behalf Of Mark Waterbury Sent: Monday, September 2, 2024 12:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: questions on HLL support of > 31-bit addressing Does anyone happen to know and can tell me whether and when any of the IBM higher level language compilers (C, COBOL, FORTRAN, PL/I) are enabled for 64-bit addressing, and so are capable of using virtual storage "above the BAR", assuming that one would use an assembly language subroutine or one of the IBM callable service routines to allocate such storage on z/OS. For that matter, were any of those compilers "enabled" for 47-bit addressing, e.g. with the use of "access registers" (ARs) on the System 390 machines running OS/390, or even on MVS/ESA on some System/370-ESA capable models that supported ARs and the extended addressing they provided? Or was this something strictly for assembler language developers to exploit? And, when and what compilers were extended to support 31-bit addressing e.g. in MVS/XA and above? Thanks in advance. All the best, Mark S. Waterbury -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: questions on HLL support of > 31-bit addressing
Which FM? In some cases compilers are available from multiple vendors. For older compilers, e.g., Ada, Pascal, it may be difficult to locate documentation, and there's no guaranty that information in DOC holds hs made its way into formal documentation. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Monday, September 2, 2024 11:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: questions on HLL support of > 31-bit addressing I hate to do it, but for the case of the current set of compilers, RTFM please. The C, COBOL V6 and PL/I Programmers Guide manual for each language clearly show the 64-bit support is there (LP32/LP64). I haven’t dealt with Fortran since Fortran II on an IBM 1620 in college, so I can’t say whether current Fortran does or not. As for when that support was added for each language, reading the list of changes per edition of the manuals should give you that information as well, though in recent year the “continuous update” philosophy means that support for a feature or capability doesn’t necessarily track with a manual edition or even necessarily with the compiler version or even its release level. Peter From: IBM Mainframe Discussion List On Behalf Of Mark Waterbury Sent: Monday, September 2, 2024 12:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: questions on HLL support of > 31-bit addressing Does anyone happen to know and can tell me whether and when any of the IBM higher level language compilers (C, COBOL, FORTRAN, PL/I) are enabled for 64-bit addressing, and so are capable of using virtual storage "above the BAR", assuming that one would use an assembly language subroutine or one of the IBM callable service routines to allocate such storage on z/OS. For that matter, were any of those compilers "enabled" for 47-bit addressing, e.g. with the use of "access registers" (ARs) on the System 390 machines running OS/390, or even on MVS/ESA on some System/370-ESA capable models that supported ARs and the extended addressing they provided? Or was this something strictly for assembler language developers to exploit? And, when and what compilers were extended to support 31-bit addressing e.g. in MVS/XA and above? Thanks in advance. All the best, Mark S. Waterbury -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SHELLSCR installation - Liberty sos
If there are no holds then it's a bug and warrants PE status. Is there an RFE to enable marking a sysmod as one at a time by some means other than holds, with SMP enforcing it? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Brian Westerman <06ba4ed225c9-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, September 3, 2024 5:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SHELLSCR installation - Liberty sos There can be more than one, just apply them in the numeric order that they come up. You will likely want to do multiple all at once, but don't be tempted to do that, it will fail, you MUST do them one at a time. There are no special holds, you will have already received the holddata by now. Remember, just one at a time. Brian -- 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: SHELLSCR installation - Liberty sos
FSVO "covered". Putting it in the comments isn't good enough; there needs to be an appropriate hold. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Ann Kelley <06eaa6330a6e-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, September 3, 2024 7:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SHELLSCR installation - Liberty sos "This si probably covered in the PTF, but the SHELLSCR ones sometimes have to be applied one at a time in the order that they require. You can search the problem records and it will tell you about it. It's dumb, but required sometimes." I hit this a long while back, and here's what I found GIM24608E ** SHELLSCR ENTRY BBLS1803 IS NEEDED TO PROCESS HFS BBL18003 FOR SYSMOD yourmissingPTF, BUT SHELLSCR BBLS1803 IS NOT IN THE SZMR0G ZONE. GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI65815. LOCAL FIX: Apply the PTF by itself with NO Groupextend and then Apply the remaining PTF's needed from the original Apply. APPLY S(yourmissing PTF) BYPASS(HOLDSYSTEM) CHECK. SMP/E APAR IO27985 has been created to address this issue. -- 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: DEVTYPE XTIOT=YES (was Simple Rexx question)
My reading is that XTIOT is only valid with INFOLIST and UCBLIST. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Willy Jensen Sent: Monday, September 2, 2024 10:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DEVTYPE XTIOT=YES (was Simple Rexx question) I could use a working sample for the DEVTYPE macro with XTIOT=YES. I have tried DEVTYPE ddloc1,XTIOT=YES fails to assemble with message 'SECOND OPERAND REQ'D-NOT SPECIFIED' DEVTYPE ddloc1,rspaworks, but defaults to XTIOT=NO DEVTYPE ddloc1,rspa,XTIOT=YESfails to assemble with message 'The XTIOT keyword must not be coded with the minimum type of call' DEVTYPE ddloc1,(rspa,24),xtiot=YES,MF=(E,dl) followed by dl DEVTYPE MF=L runs, but returns 4 in r15 and response area is all zeros, even though the DDname SYSPRINT definitely is there. ddloc1 dccl8'SYSPRINT' rspa ds0d,xl256 I have tried a number of combinations without MF, but they fail to assemble for one reason or another, mostly with message 'The XTIOT keyword must not be coded with the minimum type of call' Or am I just overlooking something obvious? Willy -- 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: SHELLSCR installation - Liberty sos
Unless it need an edit of $PATH. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Mike Schwab <05962a42dc49-dmarc-requ...@listserv.ua.edu> Sent: Monday, September 2, 2024 11:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SHELLSCR installation - Liberty sos Prerequisites should handle it. On Mon, Sep 2, 2024 at 8:09 AM Seymour J Metz wrote: > > Are there appropriate holds? > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > > > From: IBM Mainframe Discussion List on behalf of > Brian Westerman <06ba4ed225c9-dmarc-requ...@listserv.ua.edu> > Sent: Monday, September 2, 2024 1:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SHELLSCR installation - Liberty sos > > This si probably covered in the PTF, but the SHELLSCR ones sometimes have to > be applied one at a time in the order that they require. > > You can search the problem records and it will tell you about it. It's dumb, > but required sometimes. > > Brian > > -- > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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 do I choose a subpool?
Freeing a subpool is against my religious principles: I'm a devout coward, and look to Finagle as a prophet. There are too many ways for things to go pear shaped. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Sunday, September 1, 2024 3:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How do I choose a subpool? You know what? I've decided to take @Rob's advice and do individual FREEMAINs one at a time. The code is going to run in a variety of shared ISPF and Websphere environments. No matter what subpool I choose, there is just no way of knowing that another programmer hasn't chosen to use the same subpool. Worst case doing individual FREEMAINs I will mess up his or her usage statistics. But doing subpool FREEMAINs, worst case I make a real mess. IMHO subpools would have been a lot more useful if there were a way to reserve one, or at least to check (yes, TOCTOU issues) for an unused one. At the very least the world could use a "Cheryl SMF list" of known subpool utilizations. Charles On Sun, 1 Sep 2024 19:55:45 +0300, Binyamin Dissen wrote: >Subpools 1 and 78 are used by TSO. Best to not screw with them. > >Of course zero is a no go. > >The rest should be fine. -- 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: SHELLSCR installation - Liberty sos
Are there appropriate holds? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Brian Westerman <06ba4ed225c9-dmarc-requ...@listserv.ua.edu> Sent: Monday, September 2, 2024 1:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SHELLSCR installation - Liberty sos This si probably covered in the PTF, but the SHELLSCR ones sometimes have to be applied one at a time in the order that they require. You can search the problem records and it will tell you about it. It's dumb, but required sometimes. Brian -- 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: JAVA: Can it handle TIOT read?
A single JFCB or a full ARL? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Kirk Wolf Sent: Saturday, August 31, 2024 12:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JAVA: Can it handle TIOT read? AFAIK, there isn't a nice way to extract the TIOT entries in Java. Options: 1) JZOS does have ZFile.readJFCB method which would allow you to get the JFCB for a given DDNAME, which can be handy and might serve your purposes. 2) You might try to use ZFile.peekOSMemory which is pretty ugly. You could use the JZOS record class generator to generate java classes from DSECTS for the control blocks. I'm not sure how to do this correctly without using the EXTRACT macro. 3) You could write your own JNI code and drop down into assembler to do the EXTRACT etc. Kirk Wolf Dovetailed Technologies https://coztoolkit.com/ On Fri, Aug 30, 2024, at 9:57 AM, Steve Thompson wrote: > I'm working on a project to "modernize" ALC to Java. > > And I have code that is reading the TIOT to find DDs that the > process is interested in. > > The subject is the question. I'm documenting routines (biz logic) > and the program I'm working on is a bit challenging. > > I know Java, kinda, when I see it. But I haven't found any method > for this. > > Anyone have to deal with this before (in Java)? > > Regards, > Steve Thompson > > -- > 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: JAVA: Can it handle TIOT read?
The initiator puts allocations into the TIOT; DYNALLOC supports both. There is
only one XTIOT for a jobstep, above the line.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf of
Bernd Oppolzer
Sent: Friday, August 30, 2024 4:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JAVA: Can it handle TIOT read?
I don't know much about XTIOT, sorry for my ignorance ...
some papers that I read from 2012 talk about XTIOT being related to
DYNALLOC and subsystems.
I would like to know if "normal" (?) allocations done using JCL DD
statements still go into the TIOT,
or if not, how this is controlled. If the XTIOT is different and
separate from the TIOT and cannot be
addressed from the own TCB (as before), how can it be found? Or: are
there more than one XTIOTs?
We still have lot's of places in my customer's system, where we look for
certain DDNAMEs using
the logic below (in ASSEMBLER most of the time, not in C, but that makes
no difference).
The logic, BTW, has no AMODE 24 restriction; it would work well with 31
bit pointers.
But in our system we always have batch jobs (or jobs controlling IMS DC
sessions or other things)
and we look for JCL DD statements ... and most often simple DD DUMMY
statements,
and the DD names found (or not found) are used to control some features
of the programs ...
e.g.: //NOSPIE DD DUMMY
which disables an ESPIE call in a certain ASSEMBLER startup routine.
IMO, this still works ... at least I didn't hear of any problems with
this solution so far.
Cheers,
Bernd
Am 30.08.2024 um 17:45 schrieb Farley, Peter:
> Bernd, I don’t think that code handles the XTIOT (above the line), which is
> pretty commonly standard these days.
>
> From: IBM Mainframe Discussion List On Behalf Of
> Bernd Oppolzer
> Sent: Friday, August 30, 2024 11:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JAVA: Can it handle TIOT read?
>
>
> Don't know, if this helps, but this is a function that reads the TIOT,
>
> looking for a certain DDNAME, and returning success (pointer to the TIOT
>
> entry)
>
> or fail (NULL).
>
>
>
> This is ANSI C. No DSECTs or structure definitions needed.
>
>
>
> Cheers,
>
> Bernd
>
>
>
>
>
> static char *check_ddname (char *ddname)
>
>
>
> //
>
> /* */
>
> /* Vorgegebener DDName wird gesucht */
>
> /* */
>
> //
>
>
>
> {
>
> char *adresse_tcb;
>
> char *adresse_tiot;
>
> char *laenge_tiot;
>
> char *ddname_tiot;
>
>
>
> adresse_tcb = adressiere_tcb ();
>
> adresse_tiot = *(((char **) adresse_tcb) + 3);
>
>
>
> for (laenge_tiot = adresse_tiot + 24;
>
> *laenge_tiot != 0;
>
> laenge_tiot += *laenge_tiot)
>
> {
>
> ddname_tiot = laenge_tiot + 4;
>
>
>
> if (memcmp (ddname_tiot, ddname, 8) == 0)
>
> {
>
>return ddname_tiot;
>
> }
>
> }
>
>
>
> return NULL;
>
> }
>
>
>
>
>
> Oh, I forgot the function to retrieve the address of the TCB:
>
>
>
>
>
> static char *adressiere_tcb (void)
>
>
>
> //
>
> /* */
>
> /* Über die TIOT (Task-IO-Table) */
>
> /* werden die DDNamen und die */
>
> /* zugeordneten DSNamen gesucht */
>
> /* */
>
> //
>
>
>
> {
>
> char ***cvt_pointer;
>
> char **tcb_tabelle;
>
>
>
> cvt_pointer = *((char ) 16);
>
> tcb_tabelle = *cvt_pointer;
>
> return *(tcb_tabelle + 1);
>
> }
>
>
>
> Comments in German language, sorry for that.
>
>
>
>
>
>
>
>
>
> Am 30.08.2024 um 17:13 schrieb Denis:
>
>>Have you tried to use peekOSMemory, its a bit strange to do control Block
>> hopping in Java and using this method, there is No dsect conversion or so,
>> Just Pointer Arithmetik, but it should be possible to do similar Things as
>> in Assembler.
>> https://urldefense.com/v3/__https://github.com/zsystems/java-samples/blob/master/PeekOSMemory.java__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!NEx7ohh6jGjaguKWNtdhaxAKUaFx-22ClbFpOzQ6bUKuJ3bdUqITCqnpPkn
Re: JAVA: Can it handle TIOT read?
Does EXTACT support XTIOT?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf of
Steve Beaver <050e0c375a14-dmarc-requ...@listserv.ua.edu>
Sent: Friday, August 30, 2024 12:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JAVA: Can it handle TIOT read?
I can think of one way in HLASM
EXTRACT TIOT
Sent from my iPhone
No one said I could type with one thumb
> On Aug 30, 2024, at 10:58, Lennie Bradshaw
> wrote:
>
> Maybe it's about time we requested that IBM provide a "standard interface"
> to return a list of allocated DDnames (whether from TIOT or XTIOT). All other
> information can be found using SVC 99 Info requests I think.
> Or does such a thing exist (i.e. without following pointers to the TIOT and
> scanning it)?
>
> Lennie
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Farley, Peter
> Sent: 30 August 2024 16:45
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JAVA: Can it handle TIOT read?
>
> Bernd, I don’t think that code handles the XTIOT (above the line), which is
> pretty commonly standard these days.
>
> From: IBM Mainframe Discussion List On Behalf Of
> Bernd Oppolzer
> Sent: Friday, August 30, 2024 11:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JAVA: Can it handle TIOT read?
>
>
> Don't know, if this helps, but this is a function that reads the TIOT,
>
> looking for a certain DDNAME, and returning success (pointer to the TIOT
>
> entry)
>
> or fail (NULL).
>
>
>
> This is ANSI C. No DSECTs or structure definitions needed.
>
>
>
> Cheers,
>
> Bernd
>
>
>
>
>
> static char *check_ddname (char *ddname)
>
>
>
> //
>
> /* */
>
> /* Vorgegebener DDName wird gesucht */
>
> /* */
>
> //
>
>
>
> {
>
>char *adresse_tcb;
>
>char *adresse_tiot;
>
>char *laenge_tiot;
>
>char *ddname_tiot;
>
>
>
>adresse_tcb = adressiere_tcb ();
>
>adresse_tiot = *(((char **) adresse_tcb) + 3);
>
>
>
>for (laenge_tiot = adresse_tiot + 24;
>
> *laenge_tiot != 0;
>
> laenge_tiot += *laenge_tiot)
>
>{
>
> ddname_tiot = laenge_tiot + 4;
>
>
>
> if (memcmp (ddname_tiot, ddname, 8) == 0)
>
> {
>
> return ddname_tiot;
>
> }
>
>}
>
>
>
>return NULL;
>
> }
>
>
>
>
>
> Oh, I forgot the function to retrieve the address of the TCB:
>
>
>
>
>
> static char *adressiere_tcb (void)
>
>
>
> //
>
> /* */
>
> /* Über die TIOT (Task-IO-Table) */
>
> /* werden die DDNamen und die */
>
> /* zugeordneten DSNamen gesucht */
>
> /* */
>
> //
>
>
>
> {
>
>char ***cvt_pointer;
>
>char **tcb_tabelle;
>
>
>
>cvt_pointer = *((char ) 16);
>
>tcb_tabelle = *cvt_pointer;
>
>return *(tcb_tabelle + 1);
>
> }
>
>
>
> Comments in German language, sorry for that.
>
>
>
>
>
>
>
>
>
>> Am 30.08.2024 um 17:13 schrieb Denis:
>>
>> Have you tried to use peekOSMemory, its a bit strange to do control Block
>> hopping in Java and using this method, there is No dsect conversion or so,
>> Just Pointer Arithmetik, but it should be possible to do similar Things as
>> in Assembler.
>
>> https://urldefense.com/v3/__https://github.com/zsystems/java-samples/b
>> lob/master/PeekOSMemory.java__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!NEx7oh
>> h6jGjaguKWNtdhaxAKUaFx-22ClbFpOzQ6bUKuJ3bdUqITCqnpPknJ8ySX0mHR1pByDDmZ
>> gdn9EvuMtwbilCEF6ExPzws$<https://urldefense.com/v3/__https:/github.com
>> /zsystems/java-samples/blob/master/PeekOSMemory.java__;!!Ebr-cpPeAnfNn
>> iQ8HSAI-g_K5b7VKg!NEx7ohh6jGjaguKWNtdhaxAKUaFx-22ClbFpOzQ6bUKuJ3bdUqIT
>> CqnpPknJ8ySX0mHR1pByDDmZgdn9EvuMtwbilCEF6ExPzws$>
>
>>
>
>> You could combine it with the jzos record Generator, that allows to create
>> Byte identical Java records with getter and Setter methods based on cobol
>> copybooks or Assembler dsects.
>
>>
Re: Use of, e.g., LAE in IBM macros
I was thinking of macros that allow cross-memory RX parameters. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Thursday, August 29, 2024 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Use of, e.g., LAE in IBM macros >How many IBM macros have documentation like "For both primary ASC mode callers >and AR ASC mode callers, >control parameters must be in the primary address space."? Almost all that go so far as to document this (for many others, they should but don't). Of course there are a fair number that allow their data to be ALET-qualified. >Are there any IM macros where requesting use of LAE would be reasonable? With what goal? Saving one instruction (such as doing "LAE" instead of "LR" and "CPYA")? Such a request would not be reasonable. But maybe you have a better goal in mind. For almost all services the rule is that an input AR (or input ALET) is ignored if the caller is not AR mode. There are exceptions. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: L/ST AR/GR pair?
I know of other architectures where index registers are coupled with segment pointer registers, e.g., for MULTICS, and where there are load and store pointer instructions that operate on register pairs, and it seems like an obvious facility for AR mode. My concern is code density rather than atomicity, although that would be desirable. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Tony Harminc Sent: Wednesday, August 28, 2024 1:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: L/ST AR/GR pair? On Wed, 28 Aug 2024 at 13:01, Seymour J Metz wrote: > Are there instructions to load and store both a general register and the > associated access register, or do you still need separate loads and > separate stores? > Well, LAE[Y], as has been discussed recently. But I assume you want to load arbitrarily different data into the GR and AR. And yes, those are LA-type instructions, not L-type. Are you also looking for atomicity of some sort? I don't think there's anything like PLO or Load Disjoint for ARs. Tony H. -- 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: L/ST AR/GR pair?
None of those do what I am asking for. I'm looking for single instruction equivalents to, e.g., L/LAM, ST/STAM. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Tom Harper <05bfa0e23abd-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, August 28, 2024 1:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: L/ST AR/GR pair? Samuel, BAKR/PC/PR/LAE/LAEY/EREG/EREGG are the ones I know of. Tom Harper Phoenix Software International Sent from my iPhone > On Aug 28, 2024, at 1:00 PM, Seymour J Metz wrote: > > Are there instructions to load and store both a general register and the > associated access register, or do you still need separate loads and separate > stores? > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Use of, e.g., LAE in IBM macros
How many IBM macros have documentation like "For both primary ASC mode callers and AR ASC mode callers, control parameters must be in the primary address space."? Are there any IM macros where requesting use of LAE would be reasonable? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
L/ST AR/GR pair?
Are there instructions to load and store both a general register and the associated access register, or do you still need separate loads and separate stores? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relative Instructions not generated by some IBM macros, e.g. STORAGE and ATTACHX
What is the effect of ASMMREL? Does it enable the use of anything beyond branch relative? Is it dependent on ARCHLVL? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Tuesday, August 27, 2024 9:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Relative Instructions not generated by some IBM macros, e.g. STORAGE and ATTACHX You are expected to make use of IEABRC/IEABRCX if you encounter a macro that uses base displacement branches. But I know that the post was not about branches. It is always to be expected that you need a reg to locate your static data (not your code). You might like the thought of "baseless" coding. But there is no expectation that you can accomplish that with our macros. You should be prepared to provide such addressability. As to when this would be changed? The likely answer is "never". A 6-byte instruction will generally not be used to replace a 4-byte instruction. Conditionally? Conceivably. As to when you would not have to worry about AMODE switching? With LE, that is already conceivable. If simply using z/OS services, the likely answer is "never" in general. Will the macros ever be "changed" from using "LA" or "LAE" to some long-displacement form unconditionally? Surely "no". That's the same 6-byte vs 4-byte consideration. Conditionally? Maybe. But only if a formal request is submitted. And it's more likely to happen for those macros that are tool-generated (as many of the macros created since the mid 80's are). Regarding LARL, it's the case that only the standard form can ever use it. Nothing else has any idea whether your expression is locatable relatively or by resolution of base-displacement. Could some alternate syntax be defined that lets you select between the two? Sure. Will it? Not likely. I have to believe that the use of list/execute forms is dominant. Regarding LRL, that's a good idea (again, conditionally). When these macros were created (or even when enhanced to accommodate not needing a base reg for your code), that was not an instruction that existed. And until z/OS 2.2 that was not an instruction that could be relied upon to be available according to some architecture level set (LRL was introduced on the z10 machine). The general expectation is that you can re-assemble using the new release's macros and still run that expansion on older releases (perhaps limited to those older releases that are still supported). Now that only z/OS 2.4 and up are supported (other than extended support), there are opportunities to use some instructions that were not previously OK to use. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relative Instructions not generated by some IBM macros, e.g. STORAGE and ATTACHX
LARL doesn't require a base register. If you don't need tp copy an AR, it and IILF seem like the obvious instructions. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Tony Harminc Sent: Monday, August 26, 2024 2:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Relative Instructions not generated by some IBM macros, e.g. STORAGE and ATTACHX On Mon, 26 Aug 2024 at 14:27, Binyamin Dissen < 0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 26 Aug 2024 14:06:06 -0400 Tony Harminc wrote: > [...] Don't see why a relative instruction should care about ARs. > The "relative" part of the instruction has to do with the target address, not the result. But I agree there's little point to it, since it would always be loading the AR with 0. LAEY allows addressibility before the base register and beyond 4K. > Fair enough. But we're not getting to "baseless" code. Tony H. -- 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: Relative Instructions not generated by some IBM macros, e.g. STORAGE and ATTACHX
ASMMREL? ARCHLVL=2? How old are the boxen you support? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Richard Zierdt Sent: Monday, August 26, 2024 11:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Relative Instructions not generated by some IBM macros, e.g. STORAGE and ATTACHX Writing code using relative addressing, as much as reasonably possible. Problem: some IBM macros, e.g., ATTACH(X) and STORAGE, generate L and LA(E) instructions instead of, e.g., LRL and LA(E)Y. STORAGE OBTAIN, Length=(0), Loc=(31,31) generates this instruction L 15,=AL1(B'',(0*16),(0),B'01110110') requiring a base register instead of, e.g., LRL 15,=AL1(B'',(0*16),(0),B'01110110') (Load Relative Long) which does not. ATTACHX EP=SUBTASK generates LAE 15,IHB0098 SET UP LIST ADDRESS instead of LAEY 15,IHB0098 SET UP LIST ADDRESS Temporary base-displacement addressing can be established prior to issuing these macros, but that defeats the purpose of relative addressing. These macros are included: SYSSTATE ARCHLVL=2Support for relative addressing IEABRCX DEFINE IEABRCX ENABLEChange base-displacement to relative but apply to branch instructions, not load. Any perspectives would be helpful, either with an alternative solution, or that, like taxes, you live with it. Thanks – Richard Zierdt Confidentiality Warning/Avertissement de confidentialité: This message is intended only for the named recipients. This message may contain information that is privileged or confidential. If you are not the named recipient, its employee or its agent, please notify us immediately and permanently destroy this message and any copies you may have. Ce message est destiné uniquement aux destinataires dûment nommés. Il peut contenir de l'information privilégiée ou confidentielle. Si vous n'êtes pas le destinataire dûment nommé, son employé ou son mandataire, veuillez nous aviser sans tarder et supprimer ce message ainsi que toute copie qui peut en avoir été faite. -- 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: Non-reentrant program not allowed (where?); Advantages of reentrant programs?
Is there a table showing fetch protect, key, page protect and subpool for every combination of library authorization, REFR, REFRPROT, RENT, REUS, TCB key? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Saturday, August 24, 2024 9:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Non-reentrant program not allowed (where?); Advantages of reentrant programs? It is not the case that the default has changed for when a reentrant module is placed into key 0 storage (which many equate with protecting it from stores, but of course it only protects it from non-key-0 stores). The default will never change, due to compatibility concerns. But there are options available such as REFRPROT to do some things differently than the default. And, if you care, for a key 9 task (a task attached with ATTACHX specifying KEY=NINE) a reentrant module is placed into key 0 storage whether or not the source library is authorized. Regarding REFRPROT/NOREFRPROT: The "no" version had to be provided and had to be the default, for compatibility reasons. The refreshable attribute had always been ignored by MVS / OS/390 / z/OS so there were plenty of cases where modules had been marked refreshable that weren't. In most cases, compatibility concerns win over modernizing. PLPA, pretty much by definition, is refreshable (because it actually is refreshed when backing real pages have been stolen). That's why the PLPA page data set exists. It is true that you won't successfully IPL if you try to put something into PLPA that is not marked reentrant. Surprising to me, no one has mentioned performance. Avoiding fetching a copy of the module from DASD (as can happen for a second or subsequent fetch of the same reentrant module if a loaded copy still is in play) can be a huge gain if you "load" it many times (such as once per task in a multi-tasking application). Also, be sure in a non-reentrant module to separate your "data" from your "code" (separate cache lines) to avoid significant degradation due to "store into instruction stream" effects. Is user key CSA still available? Only in a restricted way. This is RUCSA. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Non-reentrant program not allowed (where?); Advantages of reentrant programs?
Even with REFPROT=NO, programs from an authorized concatenation an marked RENT go into key 0 storage. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Lennie Bradshaw Sent: Saturday, August 24, 2024 9:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Non-reentrant program not allowed (where?); Advantages of reentrant programs? Clearly my statements below lack the degree of accuracy that is needed. Apologies. As others have stated the option is REFRPROT which refers to refreshable modules rather than reentrant modules. Also it appears that the default has not changed. So refreshable modules are loaded into non-store protected subpools by default, unless REFRPROT is specified. When it is specified, (taken from z/OS 3.1 MVS Initialization and Tuning Reference SA23-1380-60), "Note that the specification of REFRPROT will cause modules link-edited with the REFR attribute to be placed into key0, non-fetch protected, page-protected storage, regardless of their APF authorization." Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Bradshaw Sent: 23 August 2024 18:11 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Non-reentrant program not allowed (where?); Advantages of reentrant programs? In addition to what others have said, these days reentrant programs are usually loaded into store-protected subpools, even if they are not APF authorised. This protects the program from being modified by anyone else operating in the same address space, either accidentally or deliberately. As this was not always the case, and for compatibility purposes, it can be disabled for non-authorised programs, I believe. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richard Zierdt Sent: 23 August 2024 17:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Non-reentrant program not allowed (where?); Advantages of reentrant programs? Some assembly textbook authors advise always writing reentrant code "because you never know if your program will be" [placed in some library / system space]. The question is: where (e.g. what libraries) must programs be reentrant to be "allowed in" ? Besides specific libraries (if any), are there other advantages to reentrant code ? Thanks -- Richard Zierdt Confidentiality Warning/Avertissement de confidentialité: This message is intended only for the named recipients. This message may contain information that is privileged or confidential. If you are not the named recipient, its employee or its agent, please notify us immediately and permanently destroy this message and any copies you may have. Ce message est destiné uniquement aux destinataires dûment nommés. Il peut contenir de l'information privilégiée ou confidentielle. Si vous n'êtes pas le destinataire dûment nommé, son employé ou son mandataire, veuillez nous aviser sans tarder et supprimer ce message ainsi que toute copie qui peut en avoir été faite. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Non-reentrant program not allowed (where?); Advantages of reentrant programs?
LOCTR is your friend. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Binyamin Dissen <0662573e2c3a-dmarc-requ...@listserv.ua.edu> Sent: Saturday, August 24, 2024 3:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Non-reentrant program not allowed (where?); Advantages of reentrant programs? On Sat, 24 Aug 2024 01:52:46 -0500 Brian Westerman <06ba4ed225c9-dmarc-requ...@listserv.ua.edu> wrote: :>As for execution speed, there is no real difference, once the program starts, code is code. If the working storage is proximate to the code there will be a performance cost as data and code use different cache lines. So a change to data near code will require the cache line to be written to storage and read back into the code cache. -- Binyamin Dissen http://secure-web.cisco.com/1iT1nyNJBgPBXhq1EDDX36-rFtiMeM1lAeJ_GTx6N-zVrmdClXnecd2aWlOUSrscWgGn8xr1ENkOky37gKlfPlch9JdmpPIb35exDlXOOkG670okFcqaSLPAd9bWAwhDBwYNH5HzWpHV1xPLkxmCY9SRoD8W0RJ-kCqWurdIUgAPQmzY9MdNQWcskJglH63PGFW2tYZB_MsB8fIZD4L1a3b9frpzR0pCCLeH1Z8Ju3m9rCOvStlE3LgGbUpRZpVjc6Vk_aXZ2jVA0iJ21pab-h7dlxhnAbgvfsOuoENmDcsjC4FbKaU4gGVM3acYlMJ4BdILE6Hrk2k_lqucT3t_lns7P194EEx-gyIMbfcbHu1oFXGoqmr_pKkH0EOTMClwhkpXbrjcxjh32i1UqG0OQJTIcy635-Zbu4PPFJiNduTg/http%3A%2F%2Fwww.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- 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: Non-reentrant program not allowed (where?); Advantages of reentrant programs?
That description is for refreshable modules, although in practice most reentrant modules are also refreshable. The binder will mark as reentrant any module that it marks as refreshable. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Roger W Suhr <06e060e1e9e7-dmarc-requ...@listserv.ua.edu> Sent: Friday, August 23, 2024 1:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Non-reentrant program not allowed (where?); Advantages of reentrant programs? Writing reentrant code is a good idea, but requires extra care, and work. It's best to use macros for program entry, and exit, for consistency, that will setup program linkage correctly and allow for the allocation of extra storage, besides the program's safe area. Reentrant programs must store any information in the program's work storage which is dynamically acquired using GETMAIN, or STORAGE macros, because they are not allowed to modify the program's area. Reentrant programs are typically in LPALIB. These programs are shared by many program's and are therefore loaded in the LPA, or ELPA. If a shared program is not reentrant, it will typically ABEND with an S0C4. The HLASM has a RENT option to make it check the code for compliance, and the BINDER option RENT, will mark the program as reentrant in the directory entry. You will also have to decide to make a programs AMODE and RMODE for at least 31 bit addressing, so they may be loaded above the 16MB Line. Get Outlook for Android<https://aka.ms/AAb9ysg> From: IBM Mainframe Discussion List on behalf of Richard Zierdt Sent: Friday, August 23, 2024 12:20:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Non-reentrant program not allowed (where?); Advantages of reentrant programs? Some assembly textbook authors advise always writing reentrant code "because you never know if your program will be" [placed in some library / system space]. The question is: where (e.g. what libraries) must programs be reentrant to be "allowed in" ? Besides specific libraries (if any), are there other advantages to reentrant code ? Thanks -- Richard Zierdt Confidentiality Warning/Avertissement de confidentialité: This message is intended only for the named recipients. This message may contain information that is privileged or confidential. If you are not the named recipient, its employee or its agent, please notify us immediately and permanently destroy this message and any copies you may have. Ce message est destiné uniquement aux destinataires dûment nommés. Il peut contenir de l'information privilégiée ou confidentielle. Si vous n'êtes pas le destinataire dûment nommé, son employé ou son mandataire, veuillez nous aviser sans tarder et supprimer ce message ainsi que toute copie qui peut en avoir été faite. -- 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: Non-reentrant program not allowed (where?); Advantages of reentrant programs?
I believe that you're thinking of REFRPROT, which refers to refreshable modules rather than reentrant modules. Note that the binder does not support marking a module as refreshable but not reentrant, although the linkage editor does. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Lennie Bradshaw Sent: Friday, August 23, 2024 1:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Non-reentrant program not allowed (where?); Advantages of reentrant programs? In addition to what others have said, these days reentrant programs are usually loaded into store-protected subpools, even if they are not APF authorised. This protects the program from being modified by anyone else operating in the same address space, either accidentally or deliberately. As this was not always the case, and for compatibility purposes, it can be disabled for non-authorised programs, I believe. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richard Zierdt Sent: 23 August 2024 17:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Non-reentrant program not allowed (where?); Advantages of reentrant programs? Some assembly textbook authors advise always writing reentrant code "because you never know if your program will be" [placed in some library / system space]. The question is: where (e.g. what libraries) must programs be reentrant to be "allowed in" ? Besides specific libraries (if any), are there other advantages to reentrant code ? Thanks -- Richard Zierdt Confidentiality Warning/Avertissement de confidentialité: This message is intended only for the named recipients. This message may contain information that is privileged or confidential. If you are not the named recipient, its employee or its agent, please notify us immediately and permanently destroy this message and any copies you may have. Ce message est destiné uniquement aux destinataires dûment nommés. Il peut contenir de l'information privilégiée ou confidentielle. Si vous n'êtes pas le destinataire dûment nommé, son employé ou son mandataire, veuillez nous aviser sans tarder et supprimer ce message ainsi que toute copie qui peut en avoir été faite. -- 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: Non-reentrant program not allowed (where?); Advantages of reentrant programs?
Anything in the LPA concatenation should be refreshable and reentrant. The advantages are: VSCR in multitasking environments. Reduced page load Some protection against bugs -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Richard Zierdt Sent: Friday, August 23, 2024 12:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Non-reentrant program not allowed (where?); Advantages of reentrant programs? Some assembly textbook authors advise always writing reentrant code "because you never know if your program will be" [placed in some library / system space]. The question is: where (e.g. what libraries) must programs be reentrant to be "allowed in" ? Besides specific libraries (if any), are there other advantages to reentrant code ? Thanks -- Richard Zierdt Confidentiality Warning/Avertissement de confidentialité: This message is intended only for the named recipients. This message may contain information that is privileged or confidential. If you are not the named recipient, its employee or its agent, please notify us immediately and permanently destroy this message and any copies you may have. Ce message est destiné uniquement aux destinataires dûment nommés. Il peut contenir de l'information privilégiée ou confidentielle. Si vous n'êtes pas le destinataire dûment nommé, son employé ou son mandataire, veuillez nous aviser sans tarder et supprimer ce message ainsi que toute copie qui peut en avoir été faite. -- 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: Simple Rexx question
The UPDAT option of OPEN is fully supported for PDS and PDSE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Thursday, August 22, 2024 3:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Simple Rexx question On Thu, 22 Aug 2024 18:33:10 +, Billy Ashton wrote: > . >For output: >to a PDS member with data: BPX was 95% faster 100% of the time (I guess >there was a lot of work to set the EOF pointer and such) >... Update-in-place PDS member? I understand this was done for UADS to obviate the need for compressing a perpetually open data set. How? BLDL; POINT; WRITE? I'd be surprised if that works for PDSE. It appears that greater design attention has been paid to the more recent facility. -- 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: Simple Rexx question
Does it dual path the SWA? BPXWDYN takes care of all the housekeeping in every
environment.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf of
Thomas Berg <0619bfe39560-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, August 22, 2024 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Simple Rexx question
Hi,
I have a rexx that extract info about allocations from current memory. I.
e. it works outside TSO. (I haven't used it in 8 years so YMMV...)
If you are interested I can send it to you.
Extract from desc text:
/* REXX
Name: EFQALLOC
Type: TSO REXX Function
Function: Returns information about current allocations.
Partially based on code stolen from Doug Nadel.
Syntax: EFQALLOC( < sel <, < options > <, output >>>)
sel Selection criteria in the form of a mask or a
complete DD- or DSname.
(If 'sel' is longer than 8 bytes or contains a '.'
it is supposed it's a DSname else that it's a
DDname.)
options Format or/and sort order of the result.
Could be: SORT SORTDD SORTDS SORTVOL SORTFLAG DD DSN
VOL FLAG ONLYDD ONLYDS ONLYVOL ODD ODS OVOL DELDUPL
output Indicates where the output should be sent.
- If empty and 'sel' is specified with one distinct
DDname it's returned as a result if called as a
function or subroutine.
- If 'RETURNVALUES' or an abbreviation thereof is
specified it's returned as a result if called as a
function or subroutine. In this case the resulting
rows (if more than one) is delimited by ';' or as
specified as a second parm after 'RETURNVALUES'.
Example: res = EFQALLOC(,,'RETURN /')
- Otherwise if empty or 'S' or 'STACK' or
'DATASTACK' it's written to the datastack.
- Otherwise if not empty it's written to that
DDname, or if a DSname, to that DS.
Exempel: rcode = EFQALLOC('ISP*','SORT DD','SYSUT2')
rcode = EFQALLOC('ISPPROF')
rcode = EFQALLOC()
--
Availible info:
Parse Value X2b(C2x(c)) With ,
is 2 , /* DSABIS INDEXED SEQUENTIAL ORGANIZATION */
ps 3 , /* DSABPS PHYSICAL SEQUENTIAL ORGANIZATION*/
da 4 , /* DSABDA DIRECT ACCESS ORGANIZATION */
cx 5 , /* DSABCX COMMUNICATIONS LINE GROUP */
cq 6 , /* DSABCQ DIRECT ACCESS MESSAGE Queue */
mq 7 , /* DSABMQ PROBLEM PROGRAM MESSAGE Queue */
po 8 , /* DSABPO PARTITIONED ORGANIZATION */
un 9 , /* DSABU UNMOVEABLE */
gs 10 , /* DSABGS GRAPHICS ORGANIZATION */
tx 11 , /* DSABTX TCAM LINE GROUP */
tq 12 , /* DSABTQ TCAM MESSAGE Queue */
13 , /* * */
vs 14 , /* DSABAM VSAM */
tr 15 , /* DSABTR TCAM 3705 */
. 16 , /* * */
. 17 , /* * */
dy 18 , /* DSABDALC DYNAMICALLY ALLOCATED */
pe 19 , /* DSABPALC PERMANENTLY ALLOCATED ATTRIBUTE */
dv 20 , /* DSABDCNV DYNAMICALLY CONVERTED */
cv 21 , /* DSABCONV CONVERTIBLE ATTRIBUTE */
dc 22 , /* DSABDCAT DYNAMICALLY CONCATENATED */
pc 23 , /* DSABPCAT PERMANENTLY CONCATENATED */
gm 24 , /* DSABCATM CONCATENATED GROUP MEMBER */
iu 25 , /* DSABNUSE IN-USE ATTRIBUTE */
op 26 , /* DSABOPEN DATA SET HAS BEEN OPENED */
rm 27 , /* DSABIRM D.S. REVERSED MERGED FOR INPUT */
uc 28 , /* DSABUNAL UNALLOCATE When CLOSED */
vl 29 , /* DSABVLF VIRTUAL LOOKASIDE FACILITY */
ch 30 , /* DSABJCHG DSNAME OR VOLSER CHANGED IN */
ni 31 , /* DSABNODI When = 1, no dataset integrity */
. 32 , /* DSABATCT Use alternate TCTIOT offset */
. 33 , /* * */
df 34 , /* DSABDEFR DEFERRED MOUNTING */
pa 35 , /* DSABPASS PASS/RETAIN IND */
vi 36 , /* DSABVAM VIO DATA SET */
vr 37 , /* DSABVMSC VIO PAGING SPACE RELEASED */
ca 38 , /* DSABCATL DATA SET IS A CATALOG */
js 39 , /* DSABJSCT JOBCA
Re: Simple Rexx question
Why? Either BPXWDYN or LISTDSI is simpler.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf of
Binyamin Dissen <0662573e2c3a-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, August 22, 2024 12:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Simple Rexx question
How about
was1=outtrap("trash.")
was2=trapmsg("on")
"EXECIO 5 DISKR Q1Q2Q3 (FINIS"
x=trapmsg(was2)
x=outtrap(was1)
if rc = 20 /*ddname not found, though trash.1 can be examined */
Let EXECIO do the work
On Wed, 21 Aug 2024 19:28:12 + Billy Ashton
<0665bda14df5-dmarc-requ...@listserv.ua.edu> wrote:
:>Hi all, I have a simple question, but my searches are eluding me (maybe
:>I don't know what to ask for).
:>
:>In my Rexx program, before I try to do an EXECIO against it, I want to
:>do something to make sure the DD statement is there and control the
:>error. I tried ListDSI, but that only works on DASD files and not on
:>instream (DD *) data.
:>
:>How can I test that I have the ABCXYZ DD statement allocated, if it is
:>DD * or DD DATA? Likewise, how can I test for DD JKLMNO that is
:>allocated to SYSOUT=* to be sure it is there (as I am writing via EXECIO
:>to it)?
:>
:>Thank you and best regards,
:>Billy Ashton
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Binyamin Dissen
http://secure-web.cisco.com/1fTNnsHZBpFAOwLB8MNIUnAL3utDNYYje9SXCSOKQzqWZQ8ViL6Ao2-ziiIjLyzoMSqhUqLnIa170KLE-7BVHVPdJ4olhlCc9r5fx27IJbzvPA4i45pYUbXd_vWD8FxgRfodrnz1huv3FpbbZA0VKKMp93J4IWkAafn_mypwOgft_5fOaFxa95zgC4EeVT8dFkkcWGX2KYHobAV9G-s3blDvQXhAQ5Ma6CUBbbVB8TzWIj2VDsjvqsAApZHnwJJWdQOwyIszMbQUas_wQtg_JLkCi0WYOR8taNqHzf9NkG3hQwU-uneB6nvAvLBYQfUeS9KIHbLl-Rx_G9yEvfPjxBj3jyRhOkj10R8IETp2qMB89iLuVc9G4imhgpbiKPMK4Mv17KS9f6JDwRMnS1qeLiw/http%3A%2F%2Fwww.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
--
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: Simple Rexx question
I've never tried it, but it should. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, August 21, 2024 6:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Simple Rexx question On Wed, 21 Aug 2024 19:54:38 +0000, Seymour J Metz wrote: >LISTDSI has a FILENAME option to test a ddname. > >r == LISTDSI(ABCXYZ FILE) > Will that work for tapes? Most infuriatingly, I learned long ago thatn LISTDSI(ABCXYZ FILE) returns attributes of the FILE as I had intended, but those from the DSCB if it can find one, simply failing if it can't. But as LBD reports, with a distinct return code. Not as useful as it might be. -- 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: Simple Rexx question
LISTDSI has a FILENAME option to test a ddname. rc = LISTDSI(ABCXYZ FILE) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Billy Ashton <0665bda14df5-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, August 21, 2024 3:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Simple Rexx question Hi all, I have a simple question, but my searches are eluding me (maybe I don't know what to ask for). In my Rexx program, before I try to do an EXECIO against it, I want to do something to make sure the DD statement is there and control the error. I tried ListDSI, but that only works on DASD files and not on instream (DD *) data. How can I test that I have the ABCXYZ DD statement allocated, if it is DD * or DD DATA? Likewise, how can I test for DD JKLMNO that is allocated to SYSOUT=* to be sure it is there (as I am writing via EXECIO to it)? Thank you and best regards, Billy Ashton -- 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: [External] : Re: How to cleanup old datasets
Do you want to uncatalog ALL of the 2x and 3x tape datasets? If so, I concur with using CSI to locate them. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Richard McIntosh <06ae244fdcf3-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, August 20, 2024 2:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] : Re: How to cleanup old datasets Yes, but how to identify all of them. The old tape volsers are 2x and 3x. Lots of different HLQs. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Tuesday, August 20, 2024 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] : Re: How to cleanup old datasets I'd suggest using access method services (IDCAMS) DELETE NOSCRATCH. -- Shmuel (Seymour J.) Metz https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!ACWV5N9M2RV99hQ!JN4Ggv-kfcKSTzkm0Bk63ypNi-hyegiozWHr6blOESFT-AQHCHcnvym2Mi1iNatPlxBhzDumN4yakdURqKs8$ עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Richard McIntosh <06ae244fdcf3-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, August 20, 2024 2:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to cleanup old datasets I have a bunch of old tape datasets that are still cataloged, but the tapes don't exist anymore. Looking for something to help in identifying all and create JCL to uncataloged them. Thanks Richard -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to cleanup old datasets
I'd suggest using access method services (IDCAMS) DELETE NOSCRATCH. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Richard McIntosh <06ae244fdcf3-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, August 20, 2024 2:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to cleanup old datasets I have a bunch of old tape datasets that are still cataloged, but the tapes don't exist anymore. Looking for something to help in identifying all and create JCL to uncataloged them. Thanks Richard -- 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: message: "You are not authorized to view the archives with the email address you used to log in."
I was posting on behalf of someone else; I forwarded your response. Thanks. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Glenn Knickerbocker Sent: Friday, August 16, 2024 11:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: message: "You are not authorized to view the archives with the email address you used to log in." On Fri, 16 Aug 2024 14:24:49 +0000, Seymour J Metz wrote: >I've never used the web interface. What is the appropriate action after >message: "You are not authorized to view the archives with the email address >you used to log in."? * Are you logged in with the same address that's subscribed to the list (sme...@gmu.edu)? * Are you looking at the right list? There are two lists and I never noticed the "-ARCHIVES" one before: > IBM-MAIN Archives > IBM Mainframe Discussion List > IBM-MAIN-ARCHIVES Archives > IBM-MAIN Archives 1986-2004 I get that message if I open the second one, because I'm not subscribed to it. When I click the hamburger in the upper right and "Subscribe or Unsubscribe," that brings up the page to subscribe. ¬R -- 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: 3270 programming
I see two issues 1. It doesn't show the command, e.g., Write Erase Alternate. TSO inserts it in some cases, but sometimes yo must do so 2. Sometime you don't need to send a field definition. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Robert Prins <05be6ef5bfea-dmarc-requ...@listserv.ua.edu> Sent: Friday, August 16, 2024 1:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 3270 programming This might also be of some use: http://secure-web.cisco.com/1evnHBgQur1qe4QJ9bNIr2HGZUk4HlLK_OYSGJDsPWa3CX5gX66Ldlk95MVqfaX6DEEJcRlrRAyTsZMzKFl2_N_pgb7OUByq67k-KttSeLJ7TKYgNVosxqUvwZnwsQts9gM291BrueeEmZINqW0xxN57m7l09t83buQa7bb0pqBjzYz9XLZ7rk-S5r4mJpyRxvB3HrmbmoYew0EZ3U5o67ZdxDb1B28wRGaghCuH-hO895xszDOmFJOTVprvB9y9s-KfyxZo5xeRjsHpVXxwWs8ZCDvh268EKWa73Nt9ZFqYgPzkGGchMfqKEkTR1iOQf0uTqPtmzrmqsdXVasgRNHSvEUJm4zXG2J93Gzx7Cz7sh_5IbmJ2_0vasDEBrJeig2EqNDvAH_C6ZJejYsacy8AnnmmAwQ4bjStcQ1JWKHNE/http%3A%2F%2Fwww.tommysprinkle.com%2Fmvs%2FP3270%2Fstart.htm - 3270 Data Stream Programming Robert On Fri, 16 Aug 2024 at 13:14, Lennie Bradshaw wrote: > Seymour, > That is interesting. I was unaware the protocol had been externalised from > IBM. I guess this absolves them of the responsibility of providing > documentation as well. > > Phil asked what was the original posters requirement. Well years ago (in > the late 1970s) I wrote some program for TSO using 3270 protocols. This was > in the days before ISPF and before the extended attribute support was > available. I have been involved in such programs rarely since then, but > have maintained some knowledge of the protocol. I have somewhere a "Green > Book" which has all the tables and so on, but I have mislaid it. I had to > make some changes to a VTAM USS table recently and was looking for the > specifications for the control strings I could use. As I couldn't find my > Green Book, I looked online and could not see where IBM had this documented. > Hence my questions. > > The website that Sebastian found was really useful. > > Many thanks to all who contributed. I will try and butt out now. > Lennie > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Seymour J Metz > Sent: 16 August 2024 12:56 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 3270 programming > > I would start with RFC 2355, TN3270 Enhancements < > https://datatracker.ietf.org/doc/rfc2355/> > > -- Robert AH Prins robert(a)prino(d)org The hitchhiking grandfather <https://secure-web.cisco.com/107B4-EWcoKgbhHZZmIUU5eIn-_Yhqfvm_RfAJhzzlD1_uMFPGmP3LLU-Y0ZcUEPFVfD-UkFm0oRtPmINtoNo-RFAdWpZrLlaX-k6fkiXyXWIioR2q_5EpmhxUDLKq19Ftbokk9Ham7DdiGwWU9F2Oi-RYrDyQaANXGyHOLPv-CKtwtJlMiTGXDnToStUfaWyfCpT_xENoMPIBOjGwxnalxB7_K8FmN0YsFsQSPDCFE3L0PEluBwu5kivEVhDP0o2w9DaQctYEhLag898b1RA0V4QkCLg0LmRYjpYZeXgg7oGSKSzrcdyFxhUok9LpNO-YhroJqcUR92DA75ctFdL_xNg51j8BDPL9PpTunhc0a6082ZkFvsOo3Cy1_EfRJAh22OXLRDtJmoGIQqD641gY-0GkWWbo9S2mIPjSV3V2RQ/https%3A%2F%2Fprino.neocities.org%2Findex.html> Some REXX code for use on z/OS <https://secure-web.cisco.com/1epy13nM1Gmr0Do6DDlTf0yGJwfGE9A2fNgQ0L-c-SPWj4BDagvxAxceu4aBOyr6vYkkSWwL6_UwaggdDpg-lx38N7GviVn8NAhR0-CS5TNJJFhY9HR7TxmMxo2NAF_U3A4bqzMpx-8Hct680a6HjnQhwcijfjtxG_oaElr73oO_VivDV0ImDp8LNFsRxgeUCr2D8SyAdhjhJfTmLyCZUXtRKLKWX4wjKMB2PuH50GUOVKlJQH0qAx75j86EAl8trbtJf9Txl33shqJQrhEPfSFXrZV8KbhzCCWEwtckFN0ShZQpVa57Ymr9C-ZzQImY_T0K8rNE50KSFVMEcq_cp2-ewcbMUrZF4H6-G9PFcEqmCIMwcOLB4K1mCFl4PNc4an2QIjPtgEfvRWKwyscZPG_WKjSWkDjD033FN0gRJuos/https%3A%2F%2Fprino.neocities.org%2FzOS%2FzOS-Tools.html> -- 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: 3270 programming
TN3270 only defines how to wrap the data stream. You still need the IBM documentation to construct or interpret the data stream. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Lennie Bradshaw Sent: Friday, August 16, 2024 9:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 3270 programming Seymour, That is interesting. I was unaware the protocol had been externalised from IBM. I guess this absolves them of the responsibility of providing documentation as well. Phil asked what was the original posters requirement. Well years ago (in the late 1970s) I wrote some program for TSO using 3270 protocols. This was in the days before ISPF and before the extended attribute support was available. I have been involved in such programs rarely since then, but have maintained some knowledge of the protocol. I have somewhere a "Green Book" which has all the tables and so on, but I have mislaid it. I had to make some changes to a VTAM USS table recently and was looking for the specifications for the control strings I could use. As I couldn't find my Green Book, I looked online and could not see where IBM had this documented. Hence my questions. The website that Sebastian found was really useful. Many thanks to all who contributed. I will try and butt out now. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 16 August 2024 12:56 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 3270 programming I would start with RFC 2355, TN3270 Enhancements <https://datatracker.ietf.org/doc/rfc2355/> -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Mike Schwab <05962a42dc49-dmarc-requ...@listserv.ua.edu> Sent: Thursday, August 15, 2024 11:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 3270 programming https://www.ibm.com/docs/en/zos-basic-skills?topic=terminal-3270-data-stream Specifically listed but no link, On Thu, Aug 15, 2024 at 7:45 PM Tom Brennan wrote: > > I don't think TN3270/TN3270E protocols are related to this manual. > They're basically just a layer used to pass the binary 3270 data > stream back and forth. > > But Lennie has a good point. I have a printed copy -05 from 1990 and > it's pretty beat up. I seem to remember it on an IBM doc site until > (guessing) 2005 or so, then it was suddenly gone. Maybe someone made > a mistake in removing it, because it's certainly required for anybody > who wants to code their own 3720 screens, or simply wants to know how > things work. > > On 8/15/2024 5:33 PM, Ken Bloom wrote: > > 3270 is supported via tn3270 and tn3270E. That’s the protocol supported > > by IBM OSA or Visara CCA3074 etc. You can probably find some old coax > > manuals for native 3270. > > > > Ken > > > > > > Kenneth A. Bloom > > CEO > > Avenir Technologies Inc > > /d/b/a Visara International > > 203-984-2235 > > bl...@visara.com<mailto:bl...@visara.com> > > http://www.visara.com/<http://www.visara.com/> > > > > > > On Aug 15, 2024, at 8:22 PM, Lennie Bradshaw > > wrote: > > > > So if the protocol is still supported, and still used, and still a valid > > programming interface, why is there no *current* manual available from IBM > > documenting it? > > > > Lennie > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Jay Maynard > > Sent: 15 August 2024 23:02 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: 3270 programming > > > > I think IBM still supports 3270 access, if not the 3270s themselves. > > > > But if the data stream hasn't changed since the -7 manual was published, > > there's no need for an update... > > > > On Thu, Aug 15, 2024 at 4:54 PM Paul Gilmartin < > > 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > > > > On Thu, 15 Aug 2024 15:16:15 -0500, Mike Schwab wrote: > > > > There have been no updates. > > > > Does IBM continue to support the device? If not, there's little > > business case to provide user's manuals. > > > > Regardless, some documentation is necessary as long as IBM products > > depend on 3270 data streams. > > > > -- > > gil > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email
Re: Ability to pass symbolic variable back from REXX to JCL?
There's no way to do it in a single job. Could you instead dynamically allocate the files? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Steve Estle <05dcac13570d-dmarc-requ...@listserv.ua.edu> Sent: Friday, August 16, 2024 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Ability to pass symbolic variable back from REXX to JCL? Hello All, I know we have a lot of REXX coders / developers on here so putting this out as a "is this possible" question. Scenario: A recent effort brought a question to light. We have a home grown REXX routine that dynamically generates dataset names and saves JES job spool dataset off using IOF product routines. The dataset name generated is unique as it includes jobname, jobnumber, and Julian date, timestamp in the dynamically generated dataset name which occurs withing thisi REXX routine (we call it BTCHSAVE). I'd like the ability to access this dynamically generated dataset name as a JCL symbolic variable for subsequent downstream job steps. Is there any way that REXX variables can be somehow be shared / passed back to batch job JCL routine such that the dynamically generated dataset name can be used in subsequent steps of the job? Let me know if anyone has tried to do this or not - possibly a future IDEA for IBM. Thanks in advance, Steve Estle Peraton Systems Programmer -- 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
message: "You are not authorized to view the archives with the email address you used to log in."
I've never used the web interface. What is the appropriate action after message: "You are not authorized to view the archives with the email address you used to log in."? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3270 programming
I would start with RFC 2355, TN3270 Enhancements <https://datatracker.ietf.org/doc/rfc2355/> -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Mike Schwab <05962a42dc49-dmarc-requ...@listserv.ua.edu> Sent: Thursday, August 15, 2024 11:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 3270 programming https://www.ibm.com/docs/en/zos-basic-skills?topic=terminal-3270-data-stream Specifically listed but no link, On Thu, Aug 15, 2024 at 7:45 PM Tom Brennan wrote: > > I don't think TN3270/TN3270E protocols are related to this manual. > They're basically just a layer used to pass the binary 3270 data stream > back and forth. > > But Lennie has a good point. I have a printed copy -05 from 1990 and > it's pretty beat up. I seem to remember it on an IBM doc site until > (guessing) 2005 or so, then it was suddenly gone. Maybe someone made a > mistake in removing it, because it's certainly required for anybody who > wants to code their own 3720 screens, or simply wants to know how things > work. > > On 8/15/2024 5:33 PM, Ken Bloom wrote: > > 3270 is supported via tn3270 and tn3270E. That’s the protocol supported > > by IBM OSA or Visara CCA3074 etc. You can probably find some old coax > > manuals for native 3270. > > > > Ken > > > > > > Kenneth A. Bloom > > CEO > > Avenir Technologies Inc > > /d/b/a Visara International > > 203-984-2235 > > bl...@visara.com<mailto:bl...@visara.com> > > http://www.visara.com/<http://www.visara.com/> > > > > > > On Aug 15, 2024, at 8:22 PM, Lennie Bradshaw > > wrote: > > > > So if the protocol is still supported, and still used, and still a valid > > programming interface, why is there no *current* manual available from IBM > > documenting it? > > > > Lennie > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of > > Jay Maynard > > Sent: 15 August 2024 23:02 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: 3270 programming > > > > I think IBM still supports 3270 access, if not the 3270s themselves. > > > > But if the data stream hasn't changed since the -7 manual was published, > > there's no need for an update... > > > > On Thu, Aug 15, 2024 at 4:54 PM Paul Gilmartin < > > 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > > > > On Thu, 15 Aug 2024 15:16:15 -0500, Mike Schwab wrote: > > > > There have been no updates. > > > > Does IBM continue to support the device? If not, there's little > > business case to provide user's manuals. > > > > Regardless, some documentation is necessary as long as IBM products > > depend on 3270 data streams. > > > > -- > > gil > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > Jay Maynard > > > > -- > > 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 > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: 3270 programming
How sure are you that it is gone rather than hidden at a new URL? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Tom Brennan Sent: Thursday, August 15, 2024 8:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 3270 programming I don't think TN3270/TN3270E protocols are related to this manual. They're basically just a layer used to pass the binary 3270 data stream back and forth. But Lennie has a good point. I have a printed copy -05 from 1990 and it's pretty beat up. I seem to remember it on an IBM doc site until (guessing) 2005 or so, then it was suddenly gone. Maybe someone made a mistake in removing it, because it's certainly required for anybody who wants to code their own 3720 screens, or simply wants to know how things work. On 8/15/2024 5:33 PM, Ken Bloom wrote: > 3270 is supported via tn3270 and tn3270E. That’s the protocol supported by > IBM OSA or Visara CCA3074 etc. You can probably find some old coax manuals > for native 3270. > > Ken > > > Kenneth A. Bloom > CEO > Avenir Technologies Inc > /d/b/a Visara International > 203-984-2235 > bl...@visara.com<mailto:bl...@visara.com> > http://secure-web.cisco.com/1TLTudOBmGalet69diYRKa8DAwYoQsf0HyXJ-qgl1HuktBgJ0uBkfkUV1NKCMmu4UPY0nQUhBrwE1Q1kd-x13LCSjzvLA9sMp5Sj4gfrQGpvBF5MNHhcjMuqJvCsCM087Xiqy7hFIv9qWl5ZAcX7Y3mSRz9dC3avrK_hyHeSker_Rl6gYuLLqX4lJy-ARD9z15wtxwDOWqW3_EEYqK-EdEmJINdoEpJIgPwxjRht9iNRQwv_0TbwP4c3u4n7OvmW2fmWqneRK0ONkFCLcRMHriPqJryWpm1NL9E3ODbiL3oxpWmBf3uURKm3YLBJeQQ-ts7VC-q8oQ1WZd8Rl8mYFMFY3cZwE-deYZ02HjvHqdaeyzRe43Z1Rot576VZmXyXxzNfel90XvjHuJrHVOJGCDQ4uM6bKYsnMK5LGm-sLP1g/http%3A%2F%2Fwww.visara.com<http://secure-web.cisco.com/1zJIa_M5KqQA7KTF_jtHCXQabbrwi8Vn2jyzDMgynvIo77e-JqtYyR1v7IV8IvpByw0MnLjYoDiTqwqXMedTQ0WVnVtVL18xpBvQWcEsFANNJLghEYUE0QLLYW0LxaMtXS6ytWjNzqZhPqUs9o16fxc6dJlIbyf8Dr4pmAvZYuiFB-N3tzKchqZLvEIiF7KPx3cEypFmU_ojMqcA6rI2gToQ_F-8qCsU_M2WayEoo-vz-X7KAo8zXDRGoIe3GdlSTnISif3cEWiBEFJ7bzgI0Av7dMZ7xNVYtyMVRTutV-BKEvPMZh_dnc67qGLfYa4Mz9xDcdNBiCNmgQC5r9lhMfzJSMz55aiO8HjNLzDW28CCPQepEcJUQgHzRLTWstbV1yELJ5gTmi8Jrw0QOUCCZnRultBL4U6BnZAYS1xCAuY4/http%3A%2F%2Fwww.visara.com%2F> > > > On Aug 15, 2024, at 8:22 PM, Lennie Bradshaw > wrote: > > So if the protocol is still supported, and still used, and still a valid > programming interface, why is there no *current* manual available from IBM > documenting it? > > Lennie > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Jay Maynard > Sent: 15 August 2024 23:02 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 3270 programming > > I think IBM still supports 3270 access, if not the 3270s themselves. > > But if the data stream hasn't changed since the -7 manual was published, > there's no need for an update... > > On Thu, Aug 15, 2024 at 4:54 PM Paul Gilmartin < > 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > > On Thu, 15 Aug 2024 15:16:15 -0500, Mike Schwab wrote: > > There have been no updates. > > Does IBM continue to support the device? If not, there's little > business case to provide user's manuals. > > Regardless, some documentation is necessary as long as IBM products > depend on 3270 data streams. > > -- > gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Jay Maynard > > -- > 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 > -- 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: 3270 programming
That depends on what you mean by current. IBM still allows you to download the most recent edition. If it's not available on a dead tree, it's got good company; IBM got out of the publishing industry a long time ago. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Lennie Bradshaw Sent: Thursday, August 15, 2024 8:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 3270 programming So if the protocol is still supported, and still used, and still a valid programming interface, why is there no *current* manual available from IBM documenting it? Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jay Maynard Sent: 15 August 2024 23:02 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 3270 programming I think IBM still supports 3270 access, if not the 3270s themselves. But if the data stream hasn't changed since the -7 manual was published, there's no need for an update... On Thu, Aug 15, 2024 at 4:54 PM Paul Gilmartin < 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > On Thu, 15 Aug 2024 15:16:15 -0500, Mike Schwab wrote: > > >There have been no updates. > > > Does IBM continue to support the device? If not, there's little > business case to provide user's manuals. > > Regardless, some documentation is necessary as long as IBM products > depend on 3270 data streams. > > -- > gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- 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: DASD & UCB Addr
What volumes? Online? Allocated to your step? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Steely.Mark Sent: Tuesday, August 13, 2024 7:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DASD & UCB Addr I am trying to write a simple High level assembler program. Would like the program just to list the volume and UCB addr. I get the volume name, but I can't get the UCB addr. Any help would be appreciated. Is there a program on the CBT tape that does this. Thank -- 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: Couple of questions about job id
Those jobids are for 5 digit job numbers. Are a lot of shops still using those? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Lindy Mayfield <05a2ba9c925b-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, August 13, 2024 2:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Couple of questions about job id That field is the closest I've seen. Here's are the values I've found. STC for normal started tasks, including SUB=MSTR, JES2, Initiators, Jobid is STC* TSO for TSO users, Job ID is TSU*. OMVS for some Jobid STC* that looks like they are OMVS threads. I didn't get to check batch job. And didn't see anything with JES2. But those values don't really map 1:1 with the info I was collecting before. From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Tuesday, August 13, 2024 3:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Couple of questions about job id EXTERNAL For a given ASID, look at OUCB +B0. JES2, STC or TSO should appear. That is field OUCBSUBN which is not a programming interface. Its commentary leads me to think that there are additional possible values. 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 -- 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: Couple of questions about job id
It's a bit more than that, but I coined the term "Artificial Stupidity" (AS) to describe what it sometimes does. GIGO, and the usual rules apply. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Robert Garrett <06c5ea04058c-dmarc-requ...@listserv.ua.edu> Sent: Thursday, August 8, 2024 9:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Couple of questions about job id What is referred to as "Artificial Intelligence" is actually better described by the term "automated plagiarism". All it's capable of is collecting/rehashing/reformulating/regurgitating information that has been collected from "all over". If it provides you an answer to something, it's because somewhere/sometime a human originally provided the information that ended up being fed to the AI engine - and that information may or may not be correct depending on the original source. Roll the dice and take your chances - just like what has been transpiring on internet forums and mailing lists (like this one) for a long time. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lindy Mayfield Sent: Wednesday, August 7, 2024 11:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Couple of questions about job id ChatGpt was by the way wrong. There is no ASCBTYP field in the ASCB with a hex value that says STC, TSU, JOB, etc. A little googling shows from where it got that confusion. This is still impressive the answer AI gave. At least to me. / By the way, still looking for what control block contains the type of job. The AI was an unintended side track. -- 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: Couple of questions about job id
I vaguely recall a job type field, but I don't remember what control block it was in. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Thursday, August 8, 2024 8:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Couple of questions about job id Colin P wrote char *pJBNI; char *pJBNS; pJBNI = (char*)*(long*)(plASCB+ASCBJBNI);// for jobs pJBNS = (char*)*(long*)(plASCB+ASCBJBNS); // for started tasks #define ASCBJBNI 172L #define ASCBJBNS 176L One or the other will be zero The last line is not true as written. For example, within an initiator when a job is running, neither is zero. If you're writing product code be aware that as an address space terminates the storage pointed to by ASCBJBNS / ASCBJBNI (which is within a CSCB mapped by IEECHAIN, hence the references to CHTRKID in other posts) gets freemained so that you might have to be prepared to blow up if using the pointer to look (if it's "your" ASCB, no problem). You might instead consider ASSBJBNS / ASSBJBNI which are not pointers, rather are the 8-byte values themselves (or x'00' in the first byte indicating not available), since you can serialize against that storage being freed by having the CPU lock, then verifying that the ASCB is valid via LOCASCSB, and checking that ASCBFAIL is not on. If all is fine, then the ASCB/ASSB cannot be freed until you release the CPU lock. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Couple of questions about job id
The naming convention are different in JES2 and JES3. For JES2 they are different depending on a JESPARM option. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Lindy Mayfield <05a2ba9c925b-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, August 7, 2024 12:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Couple of questions about job id For the job id on my system, the name starts STC* for started task, TSU* for TSO user, JOB* for batch (and sometimes initiatiors), and there seems to be an 'other' category. But I noticed on another system that the jobid names are different. Out of curiosity, where is that naming defined? I didn't find it in the usual places. Since the naming convention can change, is there another way to find out the job type, STC, JOB, TSU, etc, in a control block somewhere? My program is already going through all the ASCB and related control blocks, so that would be the best place to look for that info. Thanks for your help. 🙂 Kind regards, Lindy -- 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 to "touch" mainframe files
An authorized application can directly update the VTOC, but an unauthorized application needs the allocation and OPEN. Neither the C/I nor the Initiator will open the dataset unless it is, e.g., STEPLIB. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Itschak Mugzach <0305158ad67d-dmarc-requ...@listserv.ua.edu> Sent: Monday, August 5, 2024 2:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to "touch" mainframe files I thought the op requires no allocation, no IO. VTOC alteration is the only way, I assume. ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: http://www.securiteam.co.il/ **|* On Mon, Aug 5, 2024 at 9:02 PM Seymour J Metz wrote: > No, you need an OPEN. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > > > From: IBM Mainframe Discussion List on behalf > of Toby Seguin <028ef8c142dd-dmarc-requ...@listserv.ua.edu> > Sent: Monday, August 5, 2024 1:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: How to "touch" mainframe files > > I used to run IEFBR14 with a disp of shr,keep,keep to touch a dataset. It > keeps it from going to archive without opening it. Not sure if it updates > the last used date or not. I'd assume it would. > > Andrew Huntington > Project Coordinator > SECURITY ARCHITECTURE > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to "touch" mainframe files
No, you need an OPEN. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Toby Seguin <028ef8c142dd-dmarc-requ...@listserv.ua.edu> Sent: Monday, August 5, 2024 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to "touch" mainframe files I used to run IEFBR14 with a disp of shr,keep,keep to touch a dataset. It keeps it from going to archive without opening it. Not sure if it updates the last used date or not. I'd assume it would. Andrew Huntington Project Coordinator SECURITY ARCHITECTURE -- 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: Filezilla & ZOS "native" datasets?
Syntax for logging in? Once you're in, FileZilla supports navigating with your pointing device? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Allan Staller <0632b4c7ca99-dmarc-requ...@listserv.ua.edu> Sent: Monday, August 5, 2024 9:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Filezilla & ZOS "native" datasets? Classification: Confidential Change the directory after the connection is made. Don’t remember the syntax. The behavior is as expected. Open-SSH does not support z/OS datasets. If you need that support, get the CoZ Toolkit. https://secure-web.cisco.com/1TH48bs_pRSE3iiuE33xk3Y2PphhecqMawRtUTW-HTAWe9XIRQF6xttxcGnElmxoer9Q_gkSBssw-oK8caGC9NfxjmutUI8SeA4eJocEo7PXEQTdPB0zFSjOcqqBOxc3445wSqF5kH52PpE1PCL23ct3dKA56SjJ9j7ulgFE_KbmUUIBL5RYsV8Di4xgJmzp6D_OtfgfGAR9KSfYJBMxJ4LThkm9mB3f-2RVmQB1L0AC_cd3C2bgRVF9unf1uXWwFNsSz3F6od0N4uB5yXl8QoapiZLG0E7oXirTa8jlsNgdRt27XFK2dG8pl2mLZ5QV6MfV9Tv64LKoQYsbfRpZoGurEoSMt6dfTxuvZclQKnb40cZpqPhr1r2u96fuUsjYoCgNZXtF527NRnbom41veb07YbjXj377HeqrQ-ltIkDw/https%3A%2F%2Fcoztoolkit.com%2F -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Estle Sent: Saturday, August 3, 2024 11:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Filezilla & ZOS "native" datasets? [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.] Hello, Recently downloaded Filezilla FTP client to compare with WinSCP which I've had for awhile on my PC. It appears to be a bit more "mainframe / ZOS" aware, but am trying to tailor it to be able to view traditional ZOS datasets via secure connections (SFTP) - or if that can't work I'm open to using it via native FTP as well. What I'm seeing when I connect with Filezilla to some of our systems with native FTP is by default the directory will display a list of native ZOS datasets under my TSO userid high-level-qualifier (like ISPF 3.4) but when I connect via SFTP my default directory is my Unix system file system (ZFS) for my home directory. So has anyone figured out a way to get a ZOS dataset listing directory when connecing with SFTP - if so, what needs to be tailored to make that happen? Anyone who has tips/tricks in using Filezilla is much appreciated. Thanks, Steve Estle Peraton Systems Programmer -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to "touch" mainframe files
Anything that does an OPEN will update the date. A basic LISTDSI doess not, but retrieving directory information does. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> Sent: Sunday, August 4, 2024 6:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to "touch" mainframe files W dniu 02.08.2024 o 17:04, Billy Ashton pisze: > Hi friends! Here's another in the series of "Friday Foibles!" (Why > these questions always come up on Fridays is beyond me!) > > We have a need to run a job that will perform a process like the Unix > touch command, so that the last access date of a file is updated. > > We don't want to do things like allocate, open, and print one record, > as some of these files are huge (25-50GB). The list of files is > somewhat dynamic, and may change week to week. > > Does anyone have a job that will update the last access date for a > list of files, and ideally, set the last access date into the future a > week or two, to ensure that the files will not get archived (since I > am not sure we could easily recall some of them again)? IMHO "last reference date" is updated wherever ISPF user type I (info) line command in P.3.4 menu. I bet the same result can be achieved by using LISTDSI function. (caution: the above does not cover VSAM datasets) -- Radoslaw Skorupka Lodz, Poland -- 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 to "touch" mainframe files
Last OPEN. You don't have to actually read anything. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Friday, August 2, 2024 4:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to "touch" mainframe files Billy Ashton asked how to do the equivalent of a USS "touch" on a z/OS data set. I'm wondering if there's something like the C "DD:ddname" filename specification hack that could be used. I know this would seem odd: run a batch job that uses BPXwhatever to run USS "touch", but if it's possible...? This makes me realize that I don't know what "touch" actually does. I mean, I know the effect, but what does it have to do to make that happen? If it's some filesystem function, a minimal C program might be able to use the "DD:ddname" hack and that function. Googling suggests that it just opens the file and that that's sufficient to update it, but there has to be more, since it can optionally update just the last access time, without updating the last changed time. In fact, the more I think about this, I now wonder what "last referenced" even means; I assume it's time of last access, not change? Billy wrote, in part: > We don't want to do things like allocate, open, and print one record, > as some of these files are huge (25-50GB). Would you need to print a record to update "last referenced"? Shouldn't reading a record suffice? Do you even need to do that? Why does the size of the file matter here? I'm sure these are dumb questions but my in-depth filesystem knowledge is for other OSes, so I'm just knowledgeable enough to be curious... -- 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: Regina rexx translate error
That's a grave accusation, but the characters in the command in the message only have "'", not "`". BTW, "`" has a special significance in Eunix shells, but not in general. In particular, it has no special significance in Rexx, even when running on a Unix-like system. So either the code in the message is not the same as the code that got the error, or Regina has an issue with quotes. I consider the former more likely, but a hex display of the code should answer the question. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Mike Beer Sent: Thursday, August 1, 2024 4:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Regina rexx translate error Hi, the error message indicates that the first single quote might be ` (accent aigu) instead of a single quote. This character has a special meaning in Linux. Best regards Mike -Original Message- From: IBM Mainframe Discussion List On Behalf Of ITschak Mugzach Sent: Donnerstag, 1. August 2024 09:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Regina rexx translate error I know, this is a mainframe forum, but I know many of you use Regina. Anyway, the command XXX = TRanslate(XXX,' ','"') get error msgs such as: sh: -c: line 0: unexpected EOF while looking for matching `"' sh: -c": line 1: syntax error: unexpected end of file. As you can see, I do use single quotes to enclose the double quotes. Any idea how to perform this translation? I also tried xxx = translate(xxx,' ','22'x) with same errors ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * nbsp; *|* -- 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: Regina rexx translate error
Doing a cut and paste from your message into an ooRexx rexxtry session, I don't get an error, so either my initial guess was wrong or the message text is not the same as what you executed. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of ITschak Mugzach <05a7ced721d8-dmarc-requ...@listserv.ua.edu> Sent: Thursday, August 1, 2024 3:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Regina rexx translate error I know, this is a mainframe forum, but I know many of you use Regina. Anyway, the command XXX = TRanslate(XXX,' ','"') get error msgs such as: sh: -c: line 0: unexpected EOF while looking for matching `"' sh: -c": line 1: syntax error: unexpected end of file. As you can see, I do use single quotes to enclose the double quotes. Any idea how to perform this translation? I also tried xxx = translate(xxx,' ','22'x) with same errors ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * nbsp; *|* -- 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: Breaking Event Address, BEAR
Unless you're in supervisor state, I don't know of a way to do it. Dou you have a spare register so you could JAS to the message routine? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Steve Austin Sent: Monday, July 29, 2024 8:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Breaking Event Address, BEAR The code I'm dealing with has an error routine that build a message, but sometimes the message is insufficient and it would be useful to know what branched to that routine without forcing a dump. -The code Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, July 29, 2024 12:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Breaking Event Address, BEAR BEAR is not the address of the last branch, it's the address of the last breaking event. If you brnch to an OPEN and get am S213, I don't believe that there is any way to recover the branch. What is the specific scenario you're concerned with. IBM: is the BEAR at the time of a program check available to recovery exits? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Steve Austin Sent: Monday, July 29, 2024 6:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Breaking Event Address, BEAR I lied I don’t want the Breaking Event address I’d like the source of the Breaking Event address. And I’m assuming the source of the BEA is the same as the source of the branch entries in the trace table. I’d like my running program to retrieve the address of the last branch without breaking anything. Is this possible? Thanks -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- 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 -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- 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: Breaking Event Address, BEAR
What about (E)SPIE exits? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Binyamin Dissen <0662573e2c3a-dmarc-requ...@listserv.ua.edu> Sent: Monday, July 29, 2024 8:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Breaking Event Address, BEAR On Mon, 29 Jul 2024 11:58:07 + Seymour J Metz wrote: :>BEAR is not the address of the last branch, it's the address of the last breaking event. If you brnch to an OPEN and get am S213, I don't believe that there is any way to recover the branch. :>What is the specific scenario you're concerned with. :>IBM: is the BEAR at the time of a program check available to recovery exits? Yes. In the SDWA. -- Binyamin Dissen http://www.dissensoftware.com/ Director, Dissen Software, Bar & Grill - Israel -- 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: Breaking Event Address, BEAR
BEAR is not the address of the last branch, it's the address of the last breaking event. If you brnch to an OPEN and get am S213, I don't believe that there is any way to recover the branch. What is the specific scenario you're concerned with. IBM: is the BEAR at the time of a program check available to recovery exits? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Steve Austin Sent: Monday, July 29, 2024 6:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Breaking Event Address, BEAR I lied I don’t want the Breaking Event address I’d like the source of the Breaking Event address. And I’m assuming the source of the BEA is the same as the source of the branch entries in the trace table. I’d like my running program to retrieve the address of the last branch without breaking anything. Is this possible? Thanks -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- 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: Does MVCDK move 'per byte' like MVC?
Unless I'm tight on registers, I often use MVCL with a zero source length. I
haven't compared timings.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf of
Allan Staller <0632b4c7ca99-dmarc-requ...@listserv.ua.edu>
Sent: Friday, July 26, 2024 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Does MVCDK move 'per byte' like MVC?
Classification: Confidential
I always thought the MVI, MVC method was very inefficient.
If I had storage available I would always define a constant of the required
length and move it.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Tony Harminc
Sent: Friday, July 26, 2024 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Does MVCDK move 'per byte' like MVC?
[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.]
On Fri, 26 Jul 2024 at 14:44, Erik Janssen <
062c999269e8-dmarc-requ...@listserv.ua.edu> wrote:
> Hello All,
>
> I had this code in a user SVC:
> MVI DATA,X'40' BLANK OUT DATA
> MVC DATA+1(254),DATA
>
> As far as I'm aware this is a well known principle to clear a data
> area, it is explained in the POP under MVC that you can propagate a byte this
> way.
>
> Since the DATA area is provided by the caller of the user SVC I
> implemented this code to do the same with MVCDK to make sure the
> protection key of the storage area matches the callers key (in R1). The
> 'spatie' field
> is defined as 'SPATIE DCCL1' '
>
> LHI R0,L'SPATIE-1
> MVCDK DATA,SPATIEBLANK OUT DATA
> LHI R0,L'DATA-2MOVE 254 CHARS
> MVCDK DATA+1,DATA
>
> I had assumed that MVCDK would also propagate a byte this way and
> tested this on a ZD&T machine and that seemed to work ok.
>
No - MVC has a specific exemption ("When the operands overlap, the result is
obtained as if the operands were processed one byte at a time and each result
byte were stored immediately after fetching the necessary operand
byte.") from the general destructive overlap rule, and MVCDK doesn't.
> Now that we have this code on our test lpar on a z16 machine I see
> that it will shift the full contents of the DATA field one position to the
> right.
> This causes residual data from the previous call to appear.
>
> The POP says under MVCDK:
> Each of the operands is processed left to right.
> When the operands overlap destructively in real storage, the results
> in the first-operand location are unpredictable.
>
Except for this unpredictability in the case of destructive overlap, the
> storage-operand consistency rules are the same as for the MOVE (MVC)
> instruction
>
Definition for this case: "Destructive overlap is said to exist when the result
location is used as a source after the result has been stored, assuming
processing to be performed one byte at a time." Alternatively (but not in
conflict): "Operands are said to overlap destructively when the first-operand
real location is used as a source after data has been moved into it."
Did I encounter that unpredictability the POP is talking about? Is it
> possible that on a ZD&T MVCDK works byte for byte like MVC, while on
> real hardware MVCDK works more like a MVCL moving all the bytes at once?
It's entirely possible. When the POP says "unpredictable" it means a very
specific kind of unpredictable, and any implementation of the architecture is
free to do anything allowed within the "unpredictable" possibilities.
> And, if MVCDK does not work a byte at a time, what would be a correct
> solution for this? Copy a byte at a time with MVCDK in a loop, like
> the programming example in the POP with the MVCSK instruction?
>
That should work, though not with great efficiency. Why not just have a
constant containing 256 (or so) blanks, and MVCDK from that? It's a tradeoff
between CPU time and storage, and in the past storage always won, but these
days 256 bytes is generally nothing. You can even put it on a cache line
boundary for extra zip...
Tony H.
--
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.
Re: Does MVCDK move 'per byte' like MVC?
Yes, for what you are doing it is unpredictable. I believe that MVCOS with a zero source length will do what you want, -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Erik Janssen <062c999269e8-dmarc-requ...@listserv.ua.edu> Sent: Friday, July 26, 2024 2:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Does MVCDK move 'per byte' like MVC? Hello All, I had this code in a user SVC: MVI DATA,X'40' BLANK OUT DATA MVC DATA+1(254),DATA As far as I'm aware this is a well known principle to clear a data area, it is explained in the POP under MVC that you can propagate a byte this way. Since the DATA area is provided by the caller of the user SVC I implemented this code to do the same with MVCDK to make sure the protection key of the storage area matches the callers key (in R1). The 'spatie' field is defined as 'SPATIE DCCL1' ' LHI R0,L'SPATIE-1 MVCDK DATA,SPATIEBLANK OUT DATA LHI R0,L'DATA-2MOVE 254 CHARS MVCDK DATA+1,DATA I had assumed that MVCDK would also propagate a byte this way and tested this on a ZD&T machine and that seemed to work ok. Now that we have this code on our test lpar on a z16 machine I see that it will shift the full contents of the DATA field one position to the right. This causes residual data from the previous call to appear. The POP says under MVCDK: Each of the operands is processed left to right. When the operands overlap destructively in real storage, the results in the first-operand location are unpredictable. Except for this unpredictability in the case of destructive overlap, the storage-operandconsistency rules are the same as for the MOVE (MVC) instruction Did I encounter that unpredictability the POP is talking about? Is it possible that on a ZD&T MVCDK works byte for byte like MVC, while on real hardware MVCDK works more like a MVCL moving all the bytes at once? And, if MVCDK does not work a byte at a time, what would be a correct solution for this? Copy a byte at a time with MVCDK in a loop, like the programming example in the POP with the MVCSK instruction? Kind regards, Erik Janssen. -- 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: Very old IBM Manuals
If you are able to provide scans to bitsavers.org, you would be doing us all a favor. BTW, does the collection include the RPQ for negative index registers and table lookup equal on the 650? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Robert Prins <05be6ef5bfea-dmarc-requ...@listserv.ua.edu> Sent: Friday, July 26, 2024 6:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Very old IBM Manuals Posted this to reddit a few days ago, so far only one "want" reaction, but I'm not sure if they are suitable for this kind of material, so if anyone here is interested, drop me a line https://www.reddit.com/r/vintagecomputing/comments/1eb63hp/very_old_ibm_manuals_looking_for_a_good_home/ Robert -- Robert AH Prins robert(a)prino(d)org The hitchhiking grandfather <https://secure-web.cisco.com/17NKv9pG8YYIpxxVbYmGctyfyA516Cta9E7E5SJs6hg5Wtvbehpr0tmpXy0NS8ijejNkTDUPc0m30x7P-MKzXfRZDF7iuckuEjAMF2aScTk7mtCbIMF7IsSXnWPmaRD5MnGauusXoyh3RrjcAxtJKxy6Jd8L33E6I2Q6LRrx8y3RtvmYOV4Sqfny1O-NuEfIso4wMNlTHXrMyWH952NFhQtsOowW6G-1jGpZVEfgkmS9CMa1dSZm0grJd8ZiTKyiEpelrAAbnvBswlg2iVaw9A4KLq2IJ9X1e8SsmBWcnCHcnugN3KuWpkQea6893__0PE8kFBQ3LNYiXVya1KwJEGEtTXGtBSLoA9NVxD_c4U75D9RbutFkSNkANzoGwOPsltErSr50xuZWMRSzjoEIRc_9LNotMoVas5aDcfWC-ukTufm8HM49YWIdzBOn9Wydn/https%3A%2F%2Fprino.neocities.org%2Findex.html> Some REXX code for use on z/OS <https://secure-web.cisco.com/1mFTVh4qHPcc_ATDQ8rABcJVuERh-frMVVqFzuk9EEM6Z4016Bqo3BXQi-qwRTkFWmXsX-KNeudwrHBXfOaDjyXjHhYERiNIx4gy4hq8V0TDOeyyTs1lJABoFBbHCVwfLMslF9KBU2EsgsXKxqkAgSrHMIwbNEcMq_wGCkUfJt_Mm4zEDnCy7tpzdad-aUKTmjNEyKcSHgITXmTgcNCwh0zxCXne_LfgrTJp6-RFMElsHK-rOYN3VCyyf3Ucp8AjiyWa8T_hpHBAMT44BSHppiwSPsj85aFMg_KdPfpi7wzZUokETMdQOhN6G2ty1FSojsC_d-DykrSLg-ag65V92jEYVGo9LHwWKyRT9pHFinjFSbtcritwIEDLgj07DpDz9DlGI6P2_hXYQ1Eb-PptuzjuAmwB8_uFDe5vB-LS_WIwet4wJr5G1t5osZPtdX_fc/https%3A%2F%2Fprino.neocities.org%2FzOS%2FzOS-Tools.html> -- 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: World’s largest computer outage!
Having an LPAR is one thing; having a system that can run in that LPAR is another. Rule 1: test everything Rule 2: see rule 1 -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Andrew Rowley Sent: Sunday, July 21, 2024 8:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: World’s largest computer outage! On 22/07/2024 10:26 am, David Spiegel wrote: > Hi Andrew, > You've just discovered the need for a 1-Pack (or 2-3 Pack) rescue > system with minimal software. > I didn't just discover it, but how many sites regularly IPL and test it? I'm sure a lot of sites assume that since they have multiple systems, there will always be an LPAR available to use for recovery. Maybe not always the case... -- Andrew Rowley Black Hill Software -- 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: World’s largest computer outage!
The good news is that there is a Plan B. The bad news is that ISBN-13 : 978-1892065001 is a novel, not a plan. Some lawyer is going to get rich off of this sort of thing. If you must outsurce, get iron-clad penaltie clauses and insurance coverage for vendor collapse. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Steve Beaver <050e0c375a14-dmarc-requ...@listserv.ua.edu> Sent: Friday, July 19, 2024 11:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: World’s largest computer outage! There is no plan B Sent from my iPhone No one said I could type with one thumb > On Jul 19, 2024, at 10:36, Schmitt, Michael wrote: > > The impact is larger than just Microsoft's cloud. The cloudstrike update is > causing crashes in Windows PCs and servers. For some it causes the PC to be > unbootable. > > (It crashed my PC but it was able to restart) > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Dave Beagle > Sent: Friday, July 19, 2024 10:19 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: World’s largest computer outing! > > lol spell check but thanks for correcting a 2nd grade word. > > > > Dave B. > > إسرائيل قتلت 40 ألف فلسطيني بريء > > > On Friday, July 19, 2024, 10:32 AM, Phil Smith III wrote: > > *outage not *outing > > The real question is how many (OK, how FEW) CxOs are going to look at this > and say "Gee, SPOF, eggs in one basket, *not under our control*, is this > cloudy thingy really such a great idea?" > > -Original Message- >>> On 7/19/24 at 9:38 AM, Dave Beagle wrote: >>> >>> Microsoft via a Crowdstrike security update is experiencing the largest >>> outage in world history. Long live the mainframe. > > -- > 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 -- 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: another z/OSMF rant. -- Catch-22 is killing me
I've always felt that a series of painful DR drills was much better than not being prepared in a real disaster, and when my boss confiscated a tape or declared key personnel dead, I heartily approved. Every obstacle you create during drills is an obstacle you'll be better prepared for when the real thing hits. You'll still get hit by the unexpected, but not as much. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> Sent: Friday, July 12, 2024 5:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: another z/OSMF rant. -- Catch-22 is killing me W dniu 11.07.2024 o 21:02, Jeremy Nicoll pisze: [...] > I recall that the first stages of our disaster recovery tests required someone > to put cartridges into 3480 drives in a machine room. We tested the whole > process (once we'd ironed out technical errors in the docs) using secretarial > staff, who knew nothing about the machines. We thought it possible that if > - say - there'd been a fire, /we/ might not be allowed into the room, but > perhaps someone like a fireman might be allowed in & needed instructions > that "anyone" could understand. It was my rule for DR drill. The youngest (in terms of employment) IT operator was responsible to read the procedure and perform IPL. To be exact, he was responsible for: - find the procedure in DR data center. Hardcopy. In some binder. In some cabinet. - start it reading - identify HMC and properc console. HMC was located in another room than consoles. Several consoles, but all of them had stickers with proper ID. - logon to HMC (yes, user and password was in the procedure) - perform POR - perform LOAD (IPL) - continue IPL process on MVS console, including start all of the subsystems, etc. Usually such guy was stressed, especially because there were some "VIP" guys behind him. However actually his role was to ...read the text. He wasn't examined. We examined the procedures. Every mistake or "I don't know what to do now" were important to me - just to fix and improve the procedure. And we repeated it. As many times as we needed. And we checked it after every major system change (z/OS upgrade, new DASD, new CPC, etc.) Finally our DR drill discussions started from the following: "OK, first we start mainframe system, it works, there is nothing to discuss. Let's look..." And it really worked that way. Our official DR test came down to 15-30 minutes of watching IPL (still performed by operator), eating pizza delivered by the management and teasing our non-mainframe colleagues and their problems. :-) -- Radoslaw Skorupka Lodz, Poland -- 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: another z/OSMF rant. -- Catch-22 is killing me
"International icons": equally unintelligible in any language. Like any technology, it's just a tool, not a magic bullet. Just because some large vendor makes a dog's breakfast of their GUI doesn't mean that GUIs are bad. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Thursday, July 11, 2024 4:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: another z/OSMF rant. -- Catch-22 is killing me Things I Wish I'd Said dept: "A GUI is like a joke: If you have to explain it, it isn't very good." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe history - 12 inch floppies?
It's older than that: <http://www.bitsavers.org/pdf/ibm/2835/GA26-1589-5_2835_2305_Reference_Oct83.pdf> 1969 -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Mike Schwab <05962a42dc49-dmarc-requ...@listserv.ua.edu> Sent: Thursday, July 11, 2024 2:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe history - 12 inch floppies? Note 3830 was the dasd string controller for 3330 volumes https://www.garlic.com/~lynn/2007d.html floppy disk was originally developed for loading microcode into the 3830 disk controller ... and was also used for loading microcode into many of the 370 mainframe machines. this typically happened automatically at power-up ... however there has been recent subthread here on the "IPL" button on 360/370 front consoles ... "initial program load" ... which was software (boot) function. However 370s also had "IMPL" button ... initial microcode program load ... if there was some service update which included replacing the microprogram floppy disk ... then the microcode could be reloaded (w/o a power cycle). 3081 had service processor and a 3310/piccolo, FBA (fixed block architecture) "hard disk" containing microcode for the 3081 processor ... and some processor functions could involve "paging" microcode from the 3310. this is different than an instruction, dynamically modifying some (frequently immediately) following instruction, in the instruction stream. a lot of 360 (software) code made use of this feature to achieve real-storage compactness (compared to paging which also is oriented towards real-storage compactness). However, it was something of a performance penalty as processors started attempting to squeeze instruction latency ... doing instruction decode and setup overlapped with execution ... there had to be constant checking if some previous instruction had modified a following instruction that had already been fetched and decoded. No details in 6th edition November 1976 of 3830/3330 manual https://bitsavers.org/pdf/ibm/3830/GA26-1592-5_Reference_Manual_for_IBM_3830_Storage_Control_Model_1_and_IBM_3330_Disk_Storage_Nov76.pdf On Thu, Jul 11, 2024 at 11:00 AM Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > > I just found information in some book that IBM mainframes used 12 inch > floppy diskettes. Late 70's. > > Anybody heard about such diskettes? > > -- > Radoslaw Skorupka > Lodz, Poland > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: another z/OSMF rant. -- Catch-22 is killing me
The Devil is in the details. Some of us have very good memories and remember how bad the "good old days", and it is a capital error to assume that everybody complaining about, e.g., DF/EF, must be a luddite. Quite often they are ranting because of real, and serious problems. That said, any hypothetical person ranting solely because it is a GUI is a very different case. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Dave Beagle <0525eaef6620-dmarc-requ...@listserv.ua.edu> Sent: Thursday, July 11, 2024 11:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: another z/OSMF rant. -- Catch-22 is killing me This thread sounds like a bunch of old people (guys mostly) complaining about how great things were when we were young. IBM had to do something to make z/OS viable to corporate America and the fact that most of us will be retired or dead in a decade. The Chinese mention about where z/OSMF was developed isn’t even remotely relevant. The Chinese are pretty smart people. Smarter than most Americans. Just look at the roster of doctors at the Cleveland/Mayo clinics or the c-suite of corporations the world over, including the US. Progress marches on regardless of whether we like it or not. Dave B. إسرائيل قتلت 40 ألف فلسطيني بريء On Thursday, July 11, 2024, 10:08 AM, Doug Fuerst wrote: No comment. Doug Fuerst -- Original Message -- From "Steve Beaver" <050e0c375a14-dmarc-requ...@listserv.ua.edu> To IBM-MAIN@LISTSERV.UA.EDU Date 7/11/2024 9:05:06 AM Subject Re: another z/OSMF rant. -- Catch-22 is killing me >The folks that wrote and are responsible for zOSMF is IBM China Labs > > >Sent from my iPhone > >No one said I could type with one thumb > >> On Jul 11, 2024, at 06:44, Doug Fuerst wrote: >> >> Back when I was an FE, we used to discuss the fact that some components >>were so difficult to replace that the designers probably never had to >>actually replace them. We always thought that the designers should have to >>replace every part we had to replace in the field before the design was >>signed off on. Never happened though... >> >> Doug Fuerst >> >> -- Original Message -- >> From "Brian Westerman" >> To IBM-MAIN@LISTSERV.UA.EDU >> Date 7/11/2024 0:32:21 AM >> Subject Re: another z/OSMF rant. -- Catch-22 is killing me >> >>> It just occurred to me that maybe the people who build z/OSMF never really >>>had to use it to build a production system. Building something that IPLs is >>>simple. building a production replacement takes some doing and having >>>someone that might not really "get" the entire process can really make the >>>process quite hard. >>> >>> Just a thought. >>> >>> Brian >>> >>> -- >>> 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 -- 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: Mainframe history - 12 inch floppies?
IBM used 8" floppies to load control code for the fixed-head disk, load microcode on the 370/145 and run diagnostics on the 370/155; I don't recall whether the used it to load compatibility microcode on the 370/165. IBM continued to ude that form factor for a long time. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> Sent: Thursday, July 11, 2024 12:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Mainframe history - 12 inch floppies? I just found information in some book that IBM mainframes used 12 inch floppy diskettes. Late 70's. Anybody heard about such diskettes? -- Radoslaw Skorupka Lodz, Poland -- 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: another z/OSMF rant. -- Catch-22 is killing me
Even when developers have to eat their own dogfood, they may be too familiar with the product to recognize issues that customers might encounter. Does anybody have access to a pool of untrained testers? IMHO, that's essential for adequately testing a user interface. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Doug Fuerst Sent: Thursday, July 11, 2024 7:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: another z/OSMF rant. -- Catch-22 is killing me Back when I was an FE, we used to discuss the fact that some components were so difficult to replace that the designers probably never had to actually replace them. We always thought that the designers should have to replace every part we had to replace in the field before the design was signed off on. Never happened though... Doug Fuerst -- Original Message -- From "Brian Westerman" To IBM-MAIN@LISTSERV.UA.EDU Date 7/11/2024 0:32:21 AM Subject Re: another z/OSMF rant. -- Catch-22 is killing me >It just occurred to me that maybe the people who build z/OSMF never really had >to use it to build a production system. Building something that IPLs is >simple. building a production replacement takes some doing and having someone >that might not really "get" the entire process can really make the process >quite hard. > >Just a thought. > >Brian > >-- >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: Off topic discussions
See section 4.3. Usenet Signature Convention in RFC 3676: ; the RFC also mentions CRLF as the line separator. Of course, it's talking about the format over the wire. It looks like outhouse has problems with trailing spaces, but I believe that I found a viable hack; type a single blank, backspace before it and then type the two hyphens. Please let me know if the "-- " now comes through. Thanks. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Wednesday, July 10, 2024 1:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Off topic discussions I'd be surprised if a current version of LISTSERV didn't remove them automatically, or at least have an option to do so--when properly formatted. OTOH, how many folks here besides him and me knew about that convention? I fear it's one that's sorta died since Usenet died. Which is a shame. Wait, convention isn't CRLF SP, it's HYPHEN HYPHEN SPACE Shmuel, I see the two hyphens but not the space in yours. Did it get stripped by your client? Or LISTSERV? Might make sure it's really still there... -- ...phsiii (note sig in above as a test to see whether a properly formatted one DOES get stripped) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pew, Curtis G Sent: Wednesday, July 10, 2024 12:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Off topic discussions On Jul 10, 2024, at 11:43 AM, Seymour J Metz wrote: Is an automatically added signature, preceded by the standard CRLF SP sig delimiter, considered part of the discussion. I would say “no”. I’m happy to ignore potentially offensive text in a signature. I really miss my old e-mail software, where I could define different automatic signatures for different recipients. Since very few email clients support this, I think it would be creating an unnecessary burden to expect people to alter their signatures just to post here. -- Curtis Pew ITS curtis@austin.utexas.edu -- 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: C interface to MVS
According to that article, "/*", "*/", "(." and ".)" are not digraphs :( -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Peter Sylvester <06091b4185f9-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 10, 2024 10:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C interface to MVS On 10/07/2024 13:03, Bernd Oppolzer wrote: > Hi, > > nice to hear, Peter ... how's the weather in Southern France? As you know there is a "NICE" city nearby. ;-) > > We wrote a C program to do the trigraph modification ... portable of course, > so that it could run on the mainframe, after the upload of the source (which > was done by the > ISPF workstation agent at that time) and just before the compile :-) Some time ago, I read the wikipedia article https://en.wikipedia.org/wiki/Digraphs_and_trigraphs_(programming) (I mention it hear because of IBM's involvement in the C++ field.. When I learned and use PASCAL in the 80's, I think I immediately had "forgotten" about (. .) begin a digraph. Someone might want to add a comment about tokenization of (.1.) vs (. 1 .) Best Peter -- 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: Off topic discussions
Except that it wasn't delimited as a signature by a line containing only hyphen hyphen space. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Dave Beagle <0525eaef6620-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 10, 2024 10:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Off topic discussions Hi Darren, I posted pro Palestinian verbiage in my signature line, not anti Jewish. And only in response to Metz’s pro Israel signature line. If the rules are to mean something, they must apply to everyone equally. Dave B. Sent from Yahoo Mail for iPhone On Wednesday, July 10, 2024, 9:52 AM, David Spiegel <0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: Hi Darren, Please forgive me i broke the rules by pointing out Dave Beagle's anti-Jewish "stationery". What should I have done differently? Thanks and regards, David On 2024-07-09 22:25, Darren Evans-Young wrote: > Please take the non-IBM-MAIN discussions offline. > I'm about to start removing folks from the list. > > Darren > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another z/OSMF rant. -- Catch-22 is killing me
The Devil is in the details. Point-and-shoot can be a timesaver. Drag-and-drop. can be a time saver. A well designed GUI can be a pleasure to work with. The fly in the ointment is that ease of use is not automatic, and a GUI for which the developer did not take into account all user requirements can be ghastly. Some issues for the developer to take into account: Is there a convenient migration path? Can the user easily script the GUI? Does the GUI preempt decisions that the user was previously able to make? Is there good recovery from failure? Is it easy to configure? Can it accommodate installation conventions? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Tom Longfellow <03e29b607131-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 10, 2024 10:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: another z/OSMF rant. -- Catch-22 is killing me Discussions about z/OSMF (or GUIs in general) can now join the list of topics like politics and religion. Lots of yelling back and forth to defend your beliefs. You will not change the other persons mind no matter what reasoning you use. The opposing side is using arguments with assumptions and facts with which you do not agree. As the victim down here where the rubber meets the road, I am just asking questions. Why? Why is it there? Didn't the prior way do the job? What is so much better under a GUI? (GUI worshippers never even think about that one). Why are the tools now more complicated that the things they support? All GUIs are a front end to something else. Eventually, you may have to go directly to the something else to get your mission accomplished. This is not new.COBOL , C and all HLLs are all front end to assembler statements. Assember is a front end to machine code. Machine code makes the bytes move. You are not going to win friends and influence people by building a new multi-part monster that front-ends the basic function. I drank the Kool-Aid back in September and installed z/OS 2.5 using the workflows. It could build a working z/OS system. However, that system could not assume the functions performed by the current system.There is a great wide world beyond the cult compound of the IBM install process. Local exits. Vendor products. Networking. Automation. All have impacts on being able to keep your job.. The answer I get back is to build your own workflows and add them to the GUI Frankenstein's monster. My brief forway into building, testing and implementing services and workflows for local customizations had such a learning code that I could not see finishing my new install in under 6 months. My decades of local experience building repeatable, reusable JCL can complete an end to end full function installation in less that a working week. To give them 'some' credit, I can see some potential benefit if I was managing a planet wide SYSPLEX and installing portable system software instances 50 times a year. I perform a new install every 2 to 3 years on two mainframes in the USA. This is done with me and the 'other guy'. I do not have a standby cadre of experts on Liberty, JAVA, HTTPS, and the rest of the GUI world. The 'not quite Silver' lining is that it will all be over for me soon. No, I am not dying, But I have watched the death of 3 mainframes in the past year with more to come in the next year. I am old enough to retire and will probably do so. -- 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: Packed Decimal -- Extended(?)
There are (not so) new instructions for IEEE decimal floating point. I don't recall whether the more recent Telum instructions included decimal. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Steve Thompson Sent: Wednesday, July 10, 2024 11:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Packed Decimal -- Extended(?) I seem to remember something said about an extension to packed decimal and new instructions. I've been looking at a recent z/Arch PoOP in pdf (IBM web site), and I can't seem to find what I hazily remember from a few years ago. Perhaps it is in a different publication. Could someone point me in the right direction, even if that is, you must have been dreaming. The issue is, how can COBOL handle larger packed decimal numbers than PACK/UNPACK can handle? I see this being a question that is going to get asked on a project I'm on And I can see special macros having to be developed for this -- Regards, Steve Thompson -- 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: Off topic discussions
Is an automatically added signature, preceded by the standard CRLF SP sig delimiter, considered part of the discussion. I really miss my old e-mail software, where I could define different automatic signatures for different recipients. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Doug Fuerst Sent: Wednesday, July 10, 2024 11:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Off topic discussions Nitpicking. You might want to consider a change to your sig as well. It is not appropriate in this forum. Doug Fuerst -- Original Message -- From "Seymour J Metz" To IBM-MAIN@LISTSERV.UA.EDU Date 7/10/2024 8:11:51 AM Subject Re: Off topic discussions >Surely IBM-MAIN also encompasses TPF, VM and VSE. What about older mainframe >operating systems, e.g., TSS? > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 >עַם יִשְׂרָאֵל חַי >נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > >From: IBM Mainframe Discussion List on behalf of >Doug Fuerst >Sent: Tuesday, July 9, 2024 11:58 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Off topic discussions > >I agree with Darren. This is a forum for technical discussions and >information exchanges for MVS systems programmers. >Anything else is simply not appropriate. Have all the opinions and >viewpoints you'd like, but on this forum, get rid of them. >That goes for everyone. > >Doug Fuerst > > > >-- Original Message -- >From "Darren Evans-Young" >To IBM-MAIN@LISTSERV.UA.EDU >Date 7/9/2024 22:25:08 PM >Subject Off topic discussions > >>Please take the non-IBM-MAIN discussions offline. >>I'm about to start removing folks from the list. >> >>Darren >> >>-- >>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 -- 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: Off topic discussions
Surely IBM-MAIN also encompasses TPF, VM and VSE. What about older mainframe operating systems, e.g., TSS? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Doug Fuerst Sent: Tuesday, July 9, 2024 11:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Off topic discussions I agree with Darren. This is a forum for technical discussions and information exchanges for MVS systems programmers. Anything else is simply not appropriate. Have all the opinions and viewpoints you'd like, but on this forum, get rid of them. That goes for everyone. Doug Fuerst -- Original Message -- From "Darren Evans-Young" To IBM-MAIN@LISTSERV.UA.EDU Date 7/9/2024 22:25:08 PM Subject Off topic discussions >Please take the non-IBM-MAIN discussions offline. >I'm about to start removing folks from the list. > >Darren > >-- >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: OS/VS2 Release 2: Happy 50th Anniversary!
Don't forget the other 1972 arrivals. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Mike Schwab <05962a42dc49-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, July 9, 2024 2:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/VS2 Release 2: Happy 50th Anniversary! 1972 OS/VS1 introduced Virtual Storage. 1974 OS/VS2 introduced Multiple Virtual Storage 1983 MVS/XA introduced 31 bit storage / I/O subsystems 1988 ESA introduced Access Registers 2000 z/OS introduced 64 bit memory. On Mon, Jul 8, 2024 at 11:23 PM Timothy Sipples wrote: > > Michael Schmitt wrote: > >What's surprising to me is that z/OS is coming up on 24 years old: > >1974: OS/VS2R2 > >1978: MVS/SE > >1980: MVS/SP > >1983: MVS/XA > >1988: MVS/ESA > >1995: OS/390 > >2000: z/OS > >Look back at the big architectural changes in MVS. So big that they > >necessitated a change in the product name each time. [Except OS/390, > >which was packaging and marketing 😊 ] > >Compared to that, z/OS seems to be stagnant. Or stable, take your > >pick. > > Well, a few points: > > 1. z/OS was introduced with the introduction of 64-bit addressing > (z/Architecture). 16 EiB of real addressable memory is still a fairly large > amount. The current model IBM z16 tops out at just shy of 40 TiB (~0.381 > EiB). Some architectural improvements have more longevity than others. Anyone > remember "extended real addressing"? > > 2. Did the name really change from 1978 to 1995? It's all "MVS," merely with > suffixes. > > 3. CICS has kept its name since at least 1968, although it dropped a prefix > in 1969. It's a good name! It's also a radically different and vastly more > capable product now. > > 4. If you want you can formally ask IBM to change the name. > > — > Timothy Sipples > Senior Architect > Digital Assets, Industry Solutions, and Cybersecurity > IBM Z/LinuxONE, Asia-Pacific > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: OS/VS2 Release 2: Happy 50th Anniversary!
"The bridge to the H series". -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Timothy Sipples Sent: Tuesday, July 9, 2024 12:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/VS2 Release 2: Happy 50th Anniversary! Michael Schmitt wrote: >What's surprising to me is that z/OS is coming up on 24 years old: >1974: OS/VS2R2 >1978: MVS/SE >1980: MVS/SP >1983: MVS/XA >1988: MVS/ESA >1995: OS/390 >2000: z/OS >Look back at the big architectural changes in MVS. So big that they >necessitated a change in the product name each time. [Except OS/390, >which was packaging and marketing 😊 ] >Compared to that, z/OS seems to be stagnant. Or stable, take your >pick. Well, a few points: 1. z/OS was introduced with the introduction of 64-bit addressing (z/Architecture). 16 EiB of real addressable memory is still a fairly large amount. The current model IBM z16 tops out at just shy of 40 TiB (~0.381 EiB). Some architectural improvements have more longevity than others. Anyone remember "extended real addressing"? 2. Did the name really change from 1978 to 1995? It's all "MVS," merely with suffixes. 3. CICS has kept its name since at least 1968, although it dropped a prefix in 1969. It's a good name! It's also a radically different and vastly more capable product now. 4. If you want you can formally ask IBM to change the name. — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: About Python and REXX
I can't speak to WSL, but only my work laptops don't have Linux. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Friday, July 5, 2024 9:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: About Python and REXX Re: “On this list there’s probably very few folks who know how to setup a user profile in USS”: If that is truly the case, I would be totally dismayed. I am not a system programmer (well, I was one for a brief moment in my career a long time ago, but not in the last 30 years) and I know very well how to set up my Unix profile so that my tasks in Unix succeed. I could not do several parts of my job without that setup done properly. Am I the only one who runs and experiments with Linux systems (and even WSL) at home for my own education? Where is the curiosity that drives us all to better our knowledge and experience? Peter From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Friday, July 5, 2024 9:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: About Python and REXX If it’s not in your PATH there’s an argument to be made that it’s not properly installed, even if the file system has been mounted. On this list there’s probably very few folks who know how to setup a user profile in USS. > On 5 Jul 2024, at 21:26, Farley, Peter > <031df298a9da-dmarc-requ...@listserv.ua.edu<mailto:031df298a9da-dmarc-requ...@listserv.ua.edu>> > wrote: > > True, if you use “type python3” it CAN find it, but the success of that > command depends on your $PATH already having the python directory listed in > it. If you don’t already know what the python3 directory is and have added > it to your $PATH, the “type” command will not find it. > > Of course if your friendly (FSVO “friendly”) sysprog has already put that > directory into your $PATH via the /etc/profile script you are GTG. > > Peter > > From: IBM Mainframe Discussion List > mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of > MANCINI Frédéric (80) > Sent: Friday, July 5, 2024 8:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> > Subject: Re: About Python and REXX > > Hello, > > To check if Python is available in the cli environment, go into OMVS, > > either from ISPF (TSO OMVS) or through a SSH connection (if the sshd > > server is running), and do > > type python > > It should return the complete PATH to the python executable. > > > > *De :* [mailto:Thomas] > > <0619bfe39560-dmarc-requ...@listserv.ua.edu<mailto:0619bfe39560-dmarc-requ...@listserv.ua.edu<mailto:0619bfe39560-dmarc-requ...@listserv.ua.edu%3cmailto:0619bfe39560-dmarc-requ...@listserv.ua.edu>>> > > *Envoyé :* jeudi 4 juillet 2024 à 00:02 > > *Pour :* > IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>> > > *Objet :* About Python and REXX > >> A question: > >> * How do I check if Python is installed/availible in an existing z/OS? (I >> can't ask anyone for the moment due to an organisational mess at this site.) > >> * Regarding REXX: > >> - If performance is a priority and concern for the task I use a proper tool >> delivered by IBM or third party vendor (the latter if portability is not >> important). > >> - If a proper tool is not avalible or usable and performance is a priority >> etc for the task I code a COBOL or assembler program. But I very seldom have >> had a need to do that, at least the latest 20 years or so. > >> - If performance is NOT a priority I use REXX. > >> - I would use langs like Python if they are as easy and fast to code as >> REXX. If not they are irrellevant for me. And here portability may probably >> be a concern. > >> - I have never felt limited by REXX functionality in z/OS (other than >> regarding performance sometimes, but then you can easily use tools from >> REXX!). > >> Thomas Berg -- 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 re
Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News
>Function programs will only execute when the > REXX function is called. That has nothing to do with the question asked: "You don't consider an application giving IRXINIT its own environments and function packages to be REXX-aware?" > Function programs will only execute when the > REXX function is called. Irrelevant to the issue at hand. > There's nothing to stop the program from being called using other methods > without a REXX environment. The fact that it is possible to write a function foo() for some other context does not mean that someone has done so, that it is usable from REXX or that it does the same thing. The issue is whether an application that provides REXX-callable application-specific functions to REXX scripts is REXX-aware, > Is defining REXX functions even necessary? Necessary for what? An application that supports user-written scripts in REXX has an API; it's an application design decision how much to include in that API. Often that includes providing functions, but it need not. > To say "at least in TSO and Unix" implies people expect > IBM to do a half assed implementation of ooRexx that > is incompatible with automation, CICS, IMS, batch rexx, > system rexx and others not mentioned. No. Had I meant that I would have written it. > Even Unix frowns upon unique programming language variants. Remember Python > 2.x vs Python 3.x. Also remember OS/2 (like all Unix variants) OS/2 is *NOT* a Unix variant. > The same ooRexx is easily used from any process. No: 1. There is no ooRexx for OS/2, because IBM did not unbundle the source for all of the packages, e.g., SOM, WPS. 2, IBM shipped bot OREXX and OREXX. > For z/OS, you must port ooRexx to automation, CICS, > IMS and more. No. > IBM REXX was designed to be environment agnostic n the sense that an application is free to provide its own environments and functions. That doesn't change with ooRexx, -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Wednesday, July 3, 2024 6:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News On Wed, 3 Jul 2024 19:46:43 +, Seymour J Metz wrote: >You don't consider an application giving IRXINIT its own environments >and function packages to be REXX-aware? Function programs will only execute when the REXX function is called. There's nothing to stop the program from being called using other methods without a REXX environment. The is not rexx-aware. IRXINIT by a product is not required for a products to use REXX. For example, Netview allows you to use the REXX API because Netview initializes REXX. You can add REXX functions to the Netview function package. Is defining REXX functions even necessary? I vaguely remember someone doing something like IEFBR14( ) without the function being defined but I could easily be wrong. >> Is ooRexx a complete replacement for IBM REXX? >OREXX is a complete replacement for SAA REXX on OS/2; > Were IBM to do port and integration of ooRexx to TSO, > I would expect it to be a complete replacement, at least in TSO and Unix > contexts. > I don't have expectations either way for System REXX. To say "at least in TSO and Unix" implies people expect IBM to do a half assed implementation of ooRexx that is incompatible with automation, CICS, IMS, batch rexx, system rexx and others not mentioned. Your expectation is for users to use 2 unique REXX variants on the same system depending upon environment. Even Unix frowns upon unique programming language variants. Remember Python 2.x vs Python 3.x. Also remember OS/2 (like all Unix variants) is a very simplistic implementation. The same ooRexx is easily used from any process. For z/OS, you must port ooRexx to automation, CICS, IMS and more. IBM REXX was designed to be environment agnostic and simple changes to incompatible routines. > I doubbt that there is a Rexx developer on the planet that would agree with > you. Most product developers would not want to deal with ooRexx and changes to their documentation. Given that IBM is not going to port ooRexx to z/OS, I suspect most REXX programmers would agree with me. With all it's blemishes, it's the same on all z/OS systems, same across all products and is fully supported / tested. -- 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: As a long-time Rexx programmer
> quote "It reads like it was written by someone who doesn't > quite understand". This was not a claim the doc was wrong. K3wl! Also totally irrelevant to your claim that "No one said tech writes got it wrong nor consistently wrong." > People were using it for decades without calling IBM support. Likewise irrelevant. > Have you ever used REXX? Have you ever learned to read? > The string past "address sdsf" is passed to SDSF. > Creating that string using REXX has nothing to do with > the SDSF command syntax. Other than the imaginary voices in your head, who claimed that it did? Is there a sale on red herrings today? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Thursday, July 4, 2024 12:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: As a long-time Rexx programmer On Wed, 3 Jul 2024 19:36:52 +, Seymour J Metz wrote: >> No one said tech writes got it wrong nor consistently wrong. >Demonstrably false. I quote "It reads like it was written by someone who doesn't quite understand". This was not a claim the doc was wrong. People were using it for decades without calling IBM support. >> The SDSF syntax is self evident >Repeating a false claim doesn't make it true. Have you ever used REXX? The string past "address sdsf" is passed to SDSF. Creating that string using REXX has nothing to do with the SDSF command syntax. Often you can use the SDSF screen command but If you need something more complex, then it's the same as can understand batch SDSF command syntax, then you'll > >> While I wouldn't recommend it, you don't need to understand the REXX >> language to write a REXX function. > >Nor did I claim that you do. > >> Instead, an ADDRESS environment is created but even that is not a >> requirement. > >It isiff you want the application to be scriptable. Otherwise, not. > >> Again, having a knowledge of REXX would be useful but by no means shouldn't >> stop anyone from using the API to create variables. > >You seem to be conflating "knowledge ff REXX" with "knowledge of REXX syntax". >Knowledge of the API is what the developer needs. > >> Again, having a knolledge of REXX would be useful but by no means shouldn't >> stop anyone from using the API to create variables. > >If they don't have knowledge of vthe API then they will have a hard time using >it. That said, some things can be done with the TSO API. > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 >עַם יִשְׂרָאֵל חַי >נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > >____ >From: IBM Mainframe Discussion List on behalf of >Jon Perryman >Sent: Wednesday, July 3, 2024 2:46 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: As a long-time Rexx programmer > >On Wed, 3 Jul 2024 16:07:21 +, Seymour J Metz wrote: > >>> The syntax is self-evident >>Alas, no; if it were hee tech writers wouldn't consistently get it wrong. > >No one said tech writes got it wrong nor consistently wrong. The original >complaint was about unusual and incomplete. REXX quoting, concatenation, >address SDSF ISFEXEC DA & more. Why have a repeat where SDSF & ISFEXEC >identify the environment. > >The SDSF syntax is self evident which is a string as used in the SDSF batch >interface. ADDRESS SDSF and quoting is a REXX paradigm documented in REXX. The >documentation doesn't require explanation of these because they are fully >documented in REXX. It would certainly be helpful knowing REXX but it is not a >requirement. > >>> IBMddesigned REXX to completely avoid the need for product developers to >>> understand REXX. >>In some cases, but if you want to defnne functions > >While I wouldn't recommend it, you don't need to understand the REXX language >to write a REXX function. > >That being said, most products rarel ccreate REXX functions because of >possible naming conflicts. Instead, an ADDRESS environment is created but >even that is not a requirement. E.g. when running in TSO skip creating an >ADDRESS environment and write a simple TSO command which by the way is called >using the TSO environment. > >> or to set REXX variables then you need to understand a bit more about the >> API. > >Again, having a knowledge of REXX would be useful but by no means shouldn't >stop anyone from using the API to create variables. > >---
Re: As a long-time Rexx programmer
> An application does not require you to initialize REXX. > TSO %MYREXX will automatically initialize REXX for all >programs executed from MYREXX exec No, the application has to have code to recognize that syntax, and ISPF is not the only application to run under TSO. Further, we seem to be talking at cross purposes; the issue is being able to script an application with REXX. > Knowledge of REXX nor knowledge of REXX syntax is needed. > The developer only needs to learn the specific API's needed > and write a very basic test of that functionality. There is no > requirement to even use one REXX API call to be REXX > compatible. FSVO "REXX compatible" that has absolutely no connection to anything I wrote. Write a TSO command processor and the command output is automatically available to REXX using outtrap. That has nothing to do with scripting the application in REXX. > The knowledge is available in the REXX documentation > for using API. Well, duh! How does that contradict "If they don't have knowledge of vthe API then they will have a hard time using it."? They have to actually read the API documentation, after which they have knowledge of it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Thursday, July 4, 2024 1:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: As a long-time Rexx programmer On Wed, 3 Jul 2024 19:36:52 +, Seymour J Metz wrote: Sorry, it submitted before I finished. >> Instead, an ADDRESS environment is created but even that is not a >> requirement. >It isiff you want the application to be scriptable. Otherwise, not. An application does not require you to initialize REXX. TSO %MYREXX will automatically initialize REXX for all programs executed from MYREXX exec. No need to create an ADDRESS environment. > >> Again, having a knowledge of REXX would be useful but by no means shouldn't >> stop anyone from using the API to create variables. >You seem to be conflating "knowledge ff REXX" with "knowledge of REXX syntax". >Knowledge of the API is what the developer needs. Knowledge of REXX nor knowledge of REXX syntax is needed. The developer only needs to learn the specific API's needed and write a very basic test of that functionality. There is no requirement to even use one REXX API call to be REXX compatible. Write a TSO command processor and the command output is automatically available to REXX using outtrap. >> Again, having a knolledge of REXX would be useful but by no means shouldn't >> stop anyone from using the API to create variables. >If they don't have knowledge of vthe API then they will have a hard time using >it. That said, some things can be done with the TSO API. The knowledge is available in the REXX documentation for using API. -- 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: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News
> Filesystem, OS/2 is oriented to drive letters, while Unix is oriented to mount points; while Unix does have drive information under /dev, it's not of concern to normal users. OS/2 doesn't have links and symbolic links, Not all Unix file systems have extended attributes. > threads, AFAIK, OS/2 doesn't have threads. > commands The commands in OS/2 are very close to PC-DOS; they are very different from those in Unix. Similarly, the shells are very different. The only points of similarity are piping and redirection. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Thursday, July 4, 2024 2:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News On Wed, 3 Jul 2024 17:32:20 +, Seymour J Metz wrote: >In what way is OS/2 remotely similar to Unix? The design concepts are very similar. The leap from OS/2 to Unix is fairly simple. , multi-tasking to name a few. z/OS on the other hand has a radically different design philosopjhy. -- 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: About Python and REXX
You can log on directly to a Eunix shell, or you can use the OMVS command under TSO. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Thomas Berg <0619bfe39560-dmarc-requ...@listserv.ua.edu> Sent: Thursday, July 4, 2024 3:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: About Python and REXX Sorry for my ignorance, how do I access OMVS? Thomas Berg Den tors 4 juli 2024 06:38Wayne Bickerdike < 059234794979-dmarc-requ...@listserv.ua.edu> skrev: > In OMVS try the python command For version 3,1, it's python3. Or just have > a look around the OMVS directories. > > On Thu, Jul 4, 2024 at 8:02 AM < > 0619bfe39560-dmarc-requ...@listserv.ua.edu> wrote: > > > A question: > > > > * How do I check if Python is installed/availible in an existing z/OS? > (I > > can't ask anyone for the moment due to an organisational mess at this > > site.) > > > > * Regarding REXX: > > - If performance is a priority and concern for the task I use a proper > > tool delivered by IBM or third party vendor (the latter if portability is > > not important). > > - If a proper tool is not avalible or usable and performance is a > priority > > etc for the task I code a COBOL or assembler program. But I very seldom > > have had a need to do that, at least the latest 20 years or so. > > - If performance is NOT a priority I use REXX. > > - I would use langs like Python if they are as easy and fast to code as > > REXX. If not they are irrellevant for me. And here portability may > probably > > be a concern. > > - I have never felt limited by REXX functionality in z/OS (other than > > regarding performance sometimes, but then you can easily use tools from > > REXX!). > > > > > > Thomas Berg > > > > -- > > 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 > -- 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: As a long-time Rexx programmer
Pretty much any ALGOL-like language, e.g., PL/I. Even for languages that are not ALGOL-like, you may need more than the address in order to pass, e.g., closures. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Eric Rossman Sent: Wednesday, July 3, 2024 3:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: As a long-time Rexx programmer But doesn't need to. So, passing just a pointer to the original is still by reference. Do you have a pointer to a reference that supports a more restrictive definition? From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Wednesday, July 3, 2024 3:24:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: As a long-time Rexx programmer Not so. The reference passed may include more than just the address. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Eric Rossman Sent: Wednesday, July 3, 2024 2:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: As a long-time Rexx programmer A difference without distinction. The real difference is that call by value makes a modifiable copy and call by reference passes a pointer to the original variable. No copy means calling by reference. Do you have a pointer to a reference that supports a more restrictive definition? -- 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: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News
You don't consider an application giving IRXINIT its own environments and function packages to be REXX-aware? > Is ooRexx a complete replacement for IBM REXX? OREXX is a complete replacement for SAA REXX on OS/2; Were IBM to do port and integration of ooRexx to TSO, I would expect it to be a complete replacement, at least in TSO and Unix contexts. I don't have expectations either way for System REXX. -- I doubbt that there is a Rexx developer on the planet that would agree with you. Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Wednesday, July 3, 2024 3:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News On Wed, 3 Jul 2024 16:11:45 +0000, Seymour J Metz wrote: >. > z/OS REXX on the other hand automatically integrates into most available >environments. >No. Various applications are REXX-aware, > and they would continue to be so were IBM to make ooRexx a supported > scripting language. There is no such thing as REXX-aware. You register your product's REXX callable routines and environment. Your product uses various REXX API's (e.g. variables). Is ooRexx a complete replacement for IBM REXX? With it's Java requirement, does CICS now support calling JAVA programs? How about products that support REXX but not JAVA? ooRexx would be a terrible language for automation because automation loses control of storage management. Those oop features come at a cost. If your product isn't essential then ooRexx is fine but can be a huge problem for system critical products. -- 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: As a long-time Rexx programmer
> No one said tech writes got it wrong nor consistently wrong. Demonstrably false. > The SDSF syntax is self evident Repeating a false claim doesn't make it true. > While I wouldn't recommend it, you don't need to understand the REXX language > to write a REXX function. Nor did I claim that you do. > Instead, an ADDRESS environment is created but even that is not a requirement. It is if you want the application to be scriptable. Otherwise, not. > Again, having a knowledge of REXX would be useful but by no means shouldn't > stop anyone from using the API to create variables. You seem to be conflating "knowledge of REXX" with "knowledge of REXX syntax". Knowledge of the API is what the developer needs. > Again, having a knowledge of REXX would be useful but by no means shouldn't > stop anyone from using the API to create variables. If they don't have knowledge of vthe API then they will have a hard time using it. That said, some things can be done with the TSO API. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Wednesday, July 3, 2024 2:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: As a long-time Rexx programmer On Wed, 3 Jul 2024 16:07:21 +, Seymour J Metz wrote: >> The syntax is self-evident >Alas, no; if it were the tech writers wouldn't consistently get it wrong. No one said tech writes got it wrong nor consistently wrong. The original complaint was about unusual and incomplete. REXX quoting, concatenation, address SDSF ISFEXEC DA & more. Why have a repeat where SDSF & ISFEXEC identify the environment. The SDSF syntax is self evident which is a string as used in the SDSF batch interface. ADDRESS SDSF and quoting is a REXX paradigm documented in REXX. The documentation doesn't require explanation of these because they are fully documented in REXX. It would certainly be helpful knowing REXX but it is not a requirement. >> IBM designed REXX to completely avoid the need for product developers to >> understand REXX. >In some cases, but if you want to defnne functions While I wouldn't recommend it, you don't need to understand the REXX language to write a REXX function. That being said, most products rarely create REXX functions because of possible naming conflicts. Instead, an ADDRESS environment is created but even that is not a requirement. E.g. when running in TSO skip creating an ADDRESS environment and write a simple TSO command which by the way is called using the TSO environment. > or to set REXX variables then you need to understand a bit more about the API. Again, having a knowledge of REXX would be useful but by no means shouldn't stop anyone from using the API to create variables. -- 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: As a long-time Rexx programmer
Not so. The reference passed may include more than just the address. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Eric Rossman Sent: Wednesday, July 3, 2024 2:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: As a long-time Rexx programmer A difference without distinction. The real difference is that call by value makes a modifiable copy and call by reference passes a pointer to the original variable. No copy means calling by reference. Do you have a pointer to a reference that supports a more restrictive definition? From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Wednesday, July 3, 2024 11:54:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: As a long-time Rexx programmer No. Call by reference is where the language processor automatically figures out what the address and associated data, e.g., array extents, are. -- Shmuel (Seymour J.) Metz -- 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: As a long-time Rexx programmer
Or the pointer includes metadata, e.g., array bounds, the maximum size of a vaying string. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Eric Rossman Sent: Wednesday, July 3, 2024 2:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: As a long-time Rexx programmer The pointer is not modifiable. The storage to which it points may be. While some languages might abstract away the actual pointer, in the end a pointer is passed for anything that doesn't fit in a register and the only difference is whether that pointer is to the original storage (by reference) or to a copy (by value). From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 3, 2024 12:07:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: As a long-time Rexx programmer On Wed, 3 Jul 2024 15:48:16 +, Eric Rossman wrote: >>call by value where the value is an address >That's the definition of call by reference. > Not quite. Only in the former case the called routine receives a modifiable local copy of that pointer. In the latter, no pointer is visible. >________ >From: Seymour J Metz >Sent: Wednesday, July 3, 2024 11:44:49 AM > >It's tot really call by reference; it's call by value where the value is an >address. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News
32 as in Intel; for z/OS it would only allow 31 or 24, with high order zeros.. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 3, 2024 1:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News On Wed, 3 Jul 2024 17:24:18 +0000, Seymour J Metz wrote: > >AFAIK the 32-bit API is compatible and the 64-bit APIiis not. > 32? As in 360/67? -- 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: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News
In what way is OS/2 remotely similar to Unix? Are you thinking of the pipe and redirection characters in the command line? If so, yhat's pretty tenuous. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Wednesday, July 3, 2024 12:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News On Wed, 3 Jul 2024 13:19:13 +0200, Rony G. Flatscher wrote: >No, it was *not* designed for Unix. It is available for Unix, Windows, Apple, >and many more >operating systems. While they may not adhere to the UNIX standards, those OS's are for all pratical purposes a UNIX variant with very similar concepts. While there are some differences, they are not completely foreign like (z/OS, z/VSE & z/VM) where OORexx will have major compatibility issues. >By the way, the first operating system IBM released ooRexx was OS/2 Warp. ooRexx was probably a simple port because of it's similarities to UNIX. >Object REXX/ooRexx has all address environments that have ever been > written for Rexx as it offers the REXX SAA interface, I'm not bashing ooRexx. I'm sure that it's a great language but as a product developer, my products effortlessly integrate in IBM REXX. > The availability of C++ APIs is one of the reasons why it has become quite > easy to integrate ooRexx with any OO system. Where is IBM REXX being used for complete applications where OOP is useful? Automation is the largest REXX user but OOP is of little use. TSO uses rexx for environmental setup and small problem resolution. >is also responsible for making it possible to implement Java interface and >abstract classes in >ooRexx classes, implementing abstract Java methods in plain [oo]Rexx! :) This is a nice feature but are these the types of problems that z/OS users want to solve using REXX? Why not just use JAVA directly since ooRexx must use it under the covers for processing Java methods. >With the Java bindings, you can integrate ooRexx with any complex application >system that offers >Java APIs, like SAP [1], PeopleSoft [2], and many more. IBM REXX environment integration is a 0 step implementation for the customer and end user. On the other hand, ooRexx requires some configuration for each ooRexx environment to be used. At a very minimum for each environment, you must define the Java libraries. For more complicated products like SAP, you must install the SAP Java connector. While these tasks seem trivial, you must remember an end user may want to use this but a system admin typically performs these tasks and must perform these on each system where ooRexx is needed. This is not automatic like in z/OS. >This support is available out of the box for Windows, Linux, and Apple. You >write one ooRexx script >on Windows and can run it unchanged on Linux or Apple, and vice versa. These are compatible UNIX variants where everything is similar. IBM Rexx exec's are not portable between z/OS, z/VM & z/VSE. The same is true for ooRexx. >> z/OS REXX on the other hand automatically integrates into most available >> environments. >Yes, because IBM created REXX and integrated it in z/OS. Too funny because REXX is not integrated in z/OS. REXX was originally written for VM and designed to be disconnected from everything by dynamic ADDRESS environments. It can be a challenge to find the REXX anchor control blocks because of the REXX execution environment (e.g. CICS, IMS TSO, automation & more). Instead of integration, it is a REXX design philosophy that does not make it OS dependent. >The problem is that IBM has never improved the REXX language on the mainframe >in the past decades, Do you think it's a coincidence that variables can't be passed between REXX members nor the ability to pass stem variables? Ask yourself why automation products implemented this capability instead of making it common to all REXX environments. I'm guessing that the lack of improvements to REXX is more about discouraging it's use as an application language than simply not improving it. >Now, ooRexx being TRL2 (and much more) would improve the productivity that >REXX allows in a >remarkable way. Hence, if offered on the mainframe, then it would allow for a >huge jump to a modern >version of REXX, buying a lot of functionality and productivity for the >customers. No doubt REXX productivity could easily be improved but there must be underlying reasons for not doing so. My guess is to limit the language use to solving trivial problems.
Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News
AFAIK the 32-bit API is compatible and the 64-bit API is not. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 3, 2024 12:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News On Wed, 3 Jul 2024 16:11:45 +0000, Seymour J Metz wrote: >. > z/OS REXX on the other hand automatically integrates into most available >environments. > >No. Various applications are REXX-aware, and they would continue to be so were >IBM to make ooRexx a supported scripting language. > Are the existing command environments "automatically" compatible with ooRexx? How much bridge code wold be needed, starting with IRXEXCOM? -- 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: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News
. > z/OS REXX on the other hand automatically integrates into most available environments. No. Various applications are REXX-aware, and they would continue to be so were IBM to make ooRexx a supported scripting language. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Wednesday, July 3, 2024 1:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News On Sun, 30 Jun 2024 13:28:20 +, Seymour J Metz wrote: >The landscape would be quite different were IBM to provide legacy streams, > port ooRexx to TSO and include BSF4ooRexx as part of z/OS. > On my PCs I've pretty much abandoned SAA Rexx. Nothing motivates IBM to port OOREXX. It is a waste of IBM manpower because it was designed for UNIX with very limited address environments and a small user community which means it's usefulness is very limited. E.g. It's certainly better than shell scripts but it hasn't replaced them. Then comes the question about integration which I'm guessing doesn't include automatic integration with SAP, PeopleSoft, various databases and much more. z/OS REXX on the other hand automatically integrates into most available environments. IBM REXX was never designed to build complicated applications. -- 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: As a long-time Rexx programmer
That's what they *should* do, but in practice they (incorrectly) infer rules from examples > IBM designed REXX to completely avoid the need for product developers to > understand REXX. In some cases, but if you want to define functions or to set REXX variables then you need to understand a bit more about the API. Still, it's not brocket science. > The syntax is self-evident Alas, no; if it were the tech writers wouldn't consistently get it wrong. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Wednesday, July 3, 2024 1:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: As a long-time Rexx programmer On Mon, 1 Jul 2024 15:01:37 +, Seymour J Metz wrote: > the question is whether they should be offering uninforme4d guesses as syntax > rules. > IMHO they should be providing tested examples and referring readers to the > Rexx documentation for details. > You create a unique REXX address environment and a simple interface (thru ADDRESS environment) that receives a string & returns REXX variables. You process the string as a command valid for your product which can be anything you want. SDSF has examples which is the only section I ever looked at. The syntax is self-evident because it follows the batch interface. I suspect the documentation refers readers to the REXX documentation but there are always people who can't connect the dots. While this isn't rocket science, the documentation exists solely to keep customers from calling support. Sometimes there is a need to cross contaminate a product's manuals to avoid the need to call support for help. -- 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
