Re: engaging off-list
On Wed, 2 Oct 2024 17:05:34 -0500, I wrote: >E-mail addresses are visible there, but you can also just click the pencil >icon to reply to a post, and you'll have options to send your reply >>To: To the List (IBM-MAIN@LISTSERV.UA.EDU) >> To the Poster (whoever@wherever) However! I found in trying to send my message to Rick that Gmail doesn't like that option: >Diagnostic-Code: smtp; 550-5.7.26 Your email has been blocked because the >sender is unauthenticated. 550-5.7.26 Gmail requires all senders to >authenticate with either SPF or DKIM. So I guess for Gmail users (and any other servers with similar policies) you'll need to copy the address and send your message directly. ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
engaging off-list
On Wed, 2 Oct 2024 17:21:51 -0400, Rick Troth wrote: >But there's a problem. I don't know how to engage off-list. In fact, to >chat with Steve is impossible because LISTSERV presents his email >address as 050e0c375a14-dmarc-requ...@listserv.ua.edu. That should be a valid address to send him a private message through LISTSERV--but the actual addresses are visible to subscribers on the archive site. You can create a login at https://listserv.ua.edu/cgi-bin/wa?GETPW1 and then see the list archives at https://listserv.ua.edu/cgi-bin/wa?A0=ibm-main E-mail addresses are visible there, but you can also just click the pencil icon to reply to a post, and you'll have options to send your reply >To:To the List (IBM-MAIN@LISTSERV.UA.EDU) > To the Poster (whoever@wherever) ¬R -- 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
Won't work for USS files, though. Those will need BPXWDYN.
https://www.ibm.com/docs/en/zos/3.1.0?topic=tef-listdsi says
> Restriction: LISTDSI does not support files in the UNIX file system.
> Unpredictable results might occur.
9 *-* "ALLOCATE DD("Arg(1)")" Arg(2)
>>>"ALLOCATE DD(SOMEFILE) PATH('/u/gsknick/some.file')"
10 *-* Call ListDSI Arg(1) "FILE"
>>>"SOMEFILE FILE"
>>>"16"
11 *-* Trace N
RESULT=16
SYSREASON =0002
SYSMSGLVL1=IKJ58400I LISTDSI FAILED. SEE REASON CODE IN VARIABLE SYSREASON.
SYSMSGLVL2=IKJ56231I UTILITY DATA SET NOT ALLOCATED, SYSTEM OR INSTALLATION
ERROR+
27 *-* Call BPXwdyn "info fi("Arg(1)") inrtdsn(inrtdsn)
inrtpath(inrtpath)"
>>> "info fi(SOMEFILE) inrtdsn(inrtdsn) inrtpath(inrtpath)"
>>> "0"
28 *-* Trace N
RESULT=0
S99MSG.0 =0
INRTDSN =...PATH=.SPECIFIED...
INRTPATH =/u/gsknick/some.file
¬R
On Thu, 22 Aug 2024 00:36:59 +, Seymour J Metz wrote:
>I've never tried it, but it should.
>
>From: IBM Mainframe Discussion List on behalf of
>Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
>Sent: Wednesday, August 21, 2024 6:16 PM
>On Wed, 21 Aug 2024 9::54:38 +, Seymour J Metz wrote:
>>LISTDSI has a FILENAEE option to test a ddname.
>>r == LISTDSI(ABCXYZ FILE)
>Will that work for tapes?
--
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."
On Fri, 16 Aug 2024 14:24:49 +, 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
Re: As a long-time Rexx programmer
On Fri, 14 Jun 2024 11:51:23 -0400, Phil Smith III wrote: >"If the command contains special characters or blanks, enclose it in single >quotation marks." > >Might not be the best example, but it's clear from the doc that whoever wrote >it doesn't understand that unassigned Rexx variables return their literal >values. Actually, it appears to be correct if unnecessary, and nothing to do with the REXX syntax. I'm not all that familiar with SDSF, but after a little experiment I'm guessing the quotes either were required at some point in the past or are needed on some but not all commands. I get the same results from these two commands to list my own jobs, with and without single quotes: "ISFEXEC ST GSK*" "ISFEXEC 'ST GSK*'" If I put the command in double quotes instead: 'ISFEXEC "ST GSK*"' I get an error telling me it's looking for quotes but not that kind: ISF302E """ was seen in command position 9 where one of the following was expected: /, QUOTED-STRING, UNQUOTED-STRING. So I think this instruction really is about the actual command as evaluated, not the syntax of specifying it in REXX. ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Archeology researce
On 5/15/2024 12:13 PM, I wrote: > Sadly, a direct link to Product Lifecycle search results doesn't work (403 > Forbidden), Hmm, maybe that was just a temporary glitch. This works for me now: > https://www.ibm.com/support/pages/lifecycle/search/?q=5655-ZOS+or+5650-ZOS+or+5694-A01 ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Archeology researce
On Wed, 15 May 2024 14:08:49 +, Allan Staller wrote: >Does anyone have links or documents to the z/OS 2.4 and 2.5 announcement >letters? For those curious or still looking, this Product Lifecycle list has links to all the General availability (GA), End of marketing (EOM), and End of support (EOS) announcements of all the z/OS releases to date: https://www.ibm.com/support/pages/lifecycle/details/?q45=S928720R89459D48 Sadly, a direct link to Product Lifecycle search results doesn't work (403 Forbidden), but you can go to https://www.ibm.com/support/pages/lifecycle/ and search for "5694-A01 or 5650-ZOS or 5655-ZOS" to find all the z/OS releases (at least until there's another new version with a new PID). ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sv: Execute Rexx from Cobol
On Tue, 7 May 2024 18:27:08 +, Lars Höglund wrote: >We had a program called JOBINFO (in allocated STEPLIB) >Didn't realize that jobinfo = jobinfo() in a Rexx will trying to start, and >maybe executing the cobolmodule >We also have a Rexx called jobinfo, and that the one I want to execute. Oh! Here's what I didn't know about the REXX function/subroutine search order on TSO until just now: https://www.ibm.com/docs/en/zos/3.1.0?topic=subroutines-search-order >If a match to the function name is not found, the function search order flag >(FUNCSOFL) is checked. The FUNCSOFL flag (see Flags and corresponding masks) >indicates whether load libraries are searched before the search for a REXX >exec. > >If the flag is off, check the load libraries. If a match to the function name >is not found, search for a REXX program. > >If the flag is on, search for a REXX program. If a match to the function name >is not found, check the load libraries. > >By default, the FUNCSOFL flag is off, which means that load libraries are >searched before the search for a REXX exec. ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Execute Rexx from Cobol
On Tue, 7 May 2024 11:33:21 +, Lars Höglund wrote: > An error has occurred in Rexx module: XMAIL > Error Type: SYNTAX > Error Line Number : 299 > Instruction : jobinfo = JOBINFO() > Return Code : 44 > Error Message text: Function did not return data So, the error here is pure REXX and has nothing to do with the COBOL caller (except that maybe it didn't provide something in the argument that XMAIL expected, or didn't set up something in the environment that JOBINFO was looking for). XMAIL called JOBINFO as a function, and JOBINFO didn't return data--not even a null value. The main routine of JOBINFO must have an EXIT or RETURN instruction somewhere with no expression specified on it, or it reached the end of the exec without executing a RETURN or EXIT instruction at all. ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx numeric digits and scientific notation question
On Thu, 14 Mar 2024 18:15:18 +, Rupert Reynolds wrote: >I *think* this only applies with calls to labels with 'procedure', but I >might be wrong. PROCEDURE only affects whether *variables* are exposed to the called routine--so it would affect the indices of the DO loops, but none of the other things that are saved across the call. >Also, there's nothing stopping us from using 'procedure exposure name1 >name2 name3' to set name1 etc. in a function that initialises them, if we >want (especially if we will want to reinitialise everything at some stage). > >Roops > >On Thu, 14 Mar 2024, 17:04 Glenn Knickerbocker, wrote: > >> On Wed, 13 Mar 2024 11:01:30 -0500, Charles Mills >> wrote: >> >And the answer is ... "The three numeric settings are automatically saved >> across internal and external subroutine and function calls." >> >I was setting numeric digits in an initialization subroutine, so Rexx >> helpfully unset it on return from initialization. I thought I had done it >> that way before but I guess I have not. >> >> Funny, I work with a lot of code that has a common subroutine for >> retrieving a TRACE setting to set in the main routine, and I never even >> thought about why, or about all the stuff that gets saved across calls! >> From CALL HELPREXX on VM: >> >> >The status of DO loops and other structures: >> --though, importantly, not the *indices* of the loops! >> >Trace action: >> >NUMERIC settings: >> >ADDRESS settings: >> >Condition traps: (CALL ON and SIGNAL ON) >> >Condition information: >> >Elapsed-time clocks: >> >OPTIONS settings: >> >> ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx numeric digits and scientific notation question
On Wed, 13 Mar 2024 11:01:30 -0500, Charles Mills wrote: >And the answer is ... "The three numeric settings are automatically saved >across internal and external subroutine and function calls." >I was setting numeric digits in an initialization subroutine, so Rexx >helpfully unset it on return from initialization. I thought I had done it that >way before but I guess I have not. Funny, I work with a lot of code that has a common subroutine for retrieving a TRACE setting to set in the main routine, and I never even thought about why, or about all the stuff that gets saved across calls! From CALL HELPREXX on VM: >The status of DO loops and other structures: --though, importantly, not the *indices* of the loops! >Trace action: >NUMERIC settings: >ADDRESS settings: >Condition traps: (CALL ON and SIGNAL ON) >Condition information: >Elapsed-time clocks: >OPTIONS settings: ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Missing LMOD doing APPLY
On Wed, 7 Feb 2024 22:07:35 +, Kurt Quackenbush wrote: >> GIM24601E ** LMOD ENTRY IEWLDR00 IS NEEDED FOR PROCESSING BUT IS NOT IN THE >> SMPCSI LIBRARY > >Are you installing the FMIDs in the waves and ripples sequence as described in >the z/OS 3.1 Program Directory? >https://www.ibm.com/docs/en/zos/3.1.0?topic=level-zos-program-directory >Which wave/ripple are you currently installing that gets this error? Can you >find where LMOD IEWLDR00 is created in the APPLY output for a prior >wave/ripple? That's the Loader, so it should be right at the start of Wave 1A in BCP, HBB77E0. --Glenn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EDIT MACRO REQUEST
On Tue, 9 Jan 2024 23:31:10 +, Schmitt, Michael wrote: >3. LMMLIST LIST STATS(YES) to create a list of the members, with statistics > While LMMLIST rc = 0 > If ZLCNORC = 0 > LMPUT to write your NONE line Of course, that assumes that there *are* already statistics. If the member has no statistics, you'll have to read it to find out if it has any records. ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LISTDSI - hardcoded dsn vs. read in from file
On Thu, 4 Jan 2024 13:55:22 -0600, Steve Estle wrote: >I've hardcoded the enclosing double quote/quote inside my file as follows: >"'SYS1.PARMLIB'" That's the problem. When your exec that works correctly does this: > DSName = "'SYS1.PARMLIB'" the double quotes are part of the REXX syntax to indicate that what's between is a literal string, and only the single quotes are part of the value of that string. When that exec then does: > Say DSName you'll see in the output just the single quotes: 'SYS1.PARMLIB' When your failing exec does: > Say dsn you'll instead see both sets of quotes, because they're both part of the data you read from the input file: "'SYS1.PARMLIB'" So don't put the double quotes in your input file, because they're not part of your data. ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Kinda fun
On Wed, 8 Nov 2023 09:49:34 -0500, Rick Troth wrote: >Cards and printed paper are even human readable. Wow. I've heard tales (probably at KTRU) of reading magnetic tape/cards with iron filings and a loupe. ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: APAR theology (was: IBM APAR Names)
On Sun, 5 Nov 2023 00:20:52 +, Seymour J Metz wrote: >IBM used to document how it assigned the prefix in sysmod ids, but its been >decades since I've seen documentation that matched practice. What I've never >seen violated is that the sysmod ids associated with an APAR all have the same >numeric portion. What *is* documented is the *range* of prefix letters used for ++APARs provided by IBM: A-K and V-Z. https://www.ibm.com/docs/en/zos/3.1.0?topic=sysmods-ptf-apar-usermod-sysmod-ids I'd be surprised if specific prefix assignments were ever documented. At first the prefix letter was normally A, and additional prefixes might be used to SUP the original ++APAR. Later, some components started using different prefix letters for each release, to make it easier to manage them in the same zone, but the letters used different by component. When we switched build tooling in 2017, I tried to make it the same by release for as many components as possible: B (to match release 7B0) for z/OS 2.3, C for 2.4, D for 2.5, now E for 3.1. But there are still a lot of exceptions for components that have more than one FMID per z/OS release. It's possible but very unlikely for the second letter and the numeric portion to differ from the APAR number. The tools will never build a ++APAR that way. Nothing stops a developer from manually editing it and changing the name, and in fact older tools allowed them to change the first letter and enter the change in the tool so the PTF would SUP it. Changing anything beyond the first letter requires an admin to enter the new name, though, and I don't recall doing that even once in 15 years. (By odd coincidence, I was just looking into the details of doing that last week, when a complicated situation arose with a fix that had been canceled in an old release, but then a new APAR was opened against that release later.) --Glenn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On Mon, 31 Jul 2023 10:54:28 -0500, Grant Taylor wrote: >> Why don't we see these systems being discussed (or maybe I just don't >> frequent the right web sites)? >I suspect it's /where/ we are talking. This list, IBM territory reddit.com/r/mainframe/ does occasionally get some Unisys discussion. Only mention of Fujitsu I found was just about a storage device, though. ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
On Thu, 13 Jul 2023 17:22:12 -0400, Phil Smith III wrote: >I've seen various schemes used for creating up-to-eight-character userids, all >truncated as needed, of course. ... >Anyone got any other variations? This is purely a curiosity item, no agenda. Standard at IBM Poughkeepsie when I started here in 1984 was department number plus initials, no choice offered to most of us. I was A17GSK. Much later I inherited what must originally have been a second ID from a coworker and eventually become his primary, H37PFH1. In between, when my organization moved "home" to Fishkill, our clunky POK userids went with us to a new Fishkill system. It was a luxury when I moved into VM support to be offered the chance to choose my own ID (just because I was new on the system, not as a support privilege). There were no name requirements at all, plenty of people using nicknames, and I briefly considered NOTR but decided keeping my initials would make searches easier and went with GSKNICK. We would have run into conflicts with the POK standard in that department, because we had two John F. P.'s. ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "National" characters
The particularly perverse one was France, code page 297, with à for @ "at," reasonable enough; £ for # "pound" but the wrong kind; and $ for $ because there was no special sign for the franc (not even a ligature of Fr). When the euro was introduced, that was really the end of trying to maintain a code point meaning "national currency unit." The new code pages kept the old national characters as is, and instead replaced the *universal* currency sign ¤ with the euro sign. ¬R On Tue, 11 Jul 2023 16:50:55 +, Gibney, Dave wrote: >US/Europe centered attitude >$ Currency - Dollar ># Weight - Pound >@ per item - at -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "National" characters
On Mon, 10 Jul 2023 11:27:04 -0500, Paul Gilmartin wrote: >The ISPF User's Guide calls "#", "$" and "@" "Special" characters; otherwise >discussing national language support. Where, specifically? In a quick search on "special character national language" in both Vol I and Vol II, I spotted only mention of national characters in the results, though I didn't go through and read each page. Oh, hmmm, trying "nls" instead of "national language," I don't know why this page was hit (most of the other hits include NL for newline) but I see what you're talking about: https://www.ibm.com/docs/en/zos/2.5.0?topic=types-member-name-conventions > Special characters are as defined in the U.S. English code page (037): > @ (X'7C'), # (X'7B'), $ (X'5B') Yeah, I agree, that should definitely be national characters. They may be extra-double-special in how they're displayed, but they're not special at all in how they're used in data set and member names. There are other contexts where special characters do reasonably include national characters, like: https://www.ibm.com/docs/en/zos/2.5.0?topic=strings-using-picture > P'$' > Any special character (not alphabetic or numeric). ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code Page for dataset names
On Wed, 5 Jul 2023 14:16:27 -0400, Matt Hogstrom wrote: >I recently ran into a question that I didn’t know the answer to. The >question was, what code page are dataset names and other z/OS artifacts coded >in? Since the special characters like #, $ and @ are different in codepages >1047, versus 037, etc does z/OS use one code page for these artifacts and >translate if a data set is created with JCL created with 1047 and is later >accessed using an 037 code page for instance ? This came up just last week over on StackOverflow: https://stackoverflow.com/questions/76569347/what-are-the-supported-code-points-for-special-characters-for-valid-z-os-datas Those three characters are the "national characters" that are, confusingly, the same code points but different glyphs in different NLS code pages. A note about them in the JCL Reference at https://www.ibm.com/docs/en/zos/2.5.0?topic=parameters-character-sets explains that the characters supported are specifically "the U.S. National characters; @ as X'7C'; $ as X'5B'; and # as X'7B'" and lookalike characters on other countries' terminals may cause errors. Hyphen '-' and all the other special characters used in JCL, on the other hand, should be invariant in all EBCDIC code pages. I haven't found documentation saying so, but they're the same in all the code pages documented for the CMS Pipelines XLATE stage. (Figure 401 at https://www.ibm.com/docs/en/SSB27U_7.3.0/pdf/c2462521.pdf) And then there's the weird one that wasn't on the standard 3270 keyboard: x'c0' is valid in data set names (but not catalog entries, so it can only be used in uncataloged data sets) and member names. It's a left-bracket in some pages, and a different-shaped left-bracket in APL, but a letter with a diacritic in others. The JCL Reference specifies it at https://www.ibm.com/docs/en/zos/2.5.0?topic=definition-unqualified-name as "a character X'C0'", not by appearance at all. ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
