Re: Anyone here exprerienced in JSON parser (assembler)
Hello Galina, I am reading IBM manuals for about 40 years, and it is hard to understand the flow of the interface calls from the manual. I first wrote a rexx program just to understand the flow. It also helped me to understand why assembler calls are not executing well. I am not sure this is a proper tool for parsing a complex, array structured JSON. But,... I already mastered the service. a sample for the next users may help them. Best, ITschak On Wed, Aug 22, 2018 at 4:42 AM Doug wrote: > Galina, > Yes, it would be worth providing sample code for batch assembler, CICS > assembler, CICS COBOL , CICS REXX , TSO REXX and ‘how to’ direction for > Liberty and eclipse. Sorry if I missed some, feel free to chime in. > By sample code we mean fully functional examples not a small KC tribute to > a hint and click for KC to direct us to yet another tiny hint. > Just my 2cents.. > Most of us are swamped with day to day problems and don’t have the extra > band width to explore as we did in days gone by. > Best Regards, > Doug > > . > > On Aug 21, 2018, at 15:08, Galina Gorelik wrote: > > Hi ITschak, > > I’m part of the team that develops the z/OS JSON parser. From your > previous post, it appears you have resolved the issue you were experiencing. > As you pointed out, we do not provider assembler samples, so you have to > connect the dots between the following three things: > 1. IBM Knowledge Center, z/OS JSON parser: Description of > HWTJ_SEARCHTYPE_GLOBAL that distinguishes between the REXX and non-REXX > parameter content: for the first “name” that exactly matches the > SearchString for REXX or the string pointed to by the SearchStringAddr > parameter for non-REXX. > 2. IBM Knowledge Center, z/OS JSON parser: Linkage considerations for > assembler language programming that specifies: Register 1 must contain the > address of a parameter list that is a list of consecutive words, each > containing the address of a parameter to be passed. > 3. HWTJIASM macro: HWTJSRCH input parameters section where the > HWTJSRCHPARMLIST DSECT shows that these are all pointers to the parameters, > in the case of the SearchStringAddr parameter, the DS indicates that this > is a pointer to the address: HWTJSRCHSEARCHSTRINGADDRPTRDS A Address > of SearchStringAddr > > Is there additional information that can be added that would have helped > more? Or verbiage that should be altered? > > Galina > > -- > 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 > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Anyone here exprerienced in JSON parser (assembler)
Galina, Yes, it would be worth providing sample code for batch assembler, CICS assembler, CICS COBOL , CICS REXX , TSO REXX and ‘how to’ direction for Liberty and eclipse. Sorry if I missed some, feel free to chime in. By sample code we mean fully functional examples not a small KC tribute to a hint and click for KC to direct us to yet another tiny hint. Just my 2cents.. Most of us are swamped with day to day problems and don’t have the extra band width to explore as we did in days gone by. Best Regards, Doug . On Aug 21, 2018, at 15:08, Galina Gorelik wrote: Hi ITschak, I’m part of the team that develops the z/OS JSON parser. From your previous post, it appears you have resolved the issue you were experiencing. As you pointed out, we do not provider assembler samples, so you have to connect the dots between the following three things: 1. IBM Knowledge Center, z/OS JSON parser: Description of HWTJ_SEARCHTYPE_GLOBAL that distinguishes between the REXX and non-REXX parameter content: for the first “name” that exactly matches the SearchString for REXX or the string pointed to by the SearchStringAddr parameter for non-REXX. 2. IBM Knowledge Center, z/OS JSON parser: Linkage considerations for assembler language programming that specifies: Register 1 must contain the address of a parameter list that is a list of consecutive words, each containing the address of a parameter to be passed. 3. HWTJIASM macro: HWTJSRCH input parameters section where the HWTJSRCHPARMLIST DSECT shows that these are all pointers to the parameters, in the case of the SearchStringAddr parameter, the DS indicates that this is a pointer to the address: HWTJSRCHSEARCHSTRINGADDRPTRDS A Address of SearchStringAddr Is there additional information that can be added that would have helped more? Or verbiage that should be altered? Galina -- 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: JES2 Spool Data Set Browse (SDSB) sample
In the absence of any clue to the contrary: of course it was mine. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Tuesday, August 21, 2018 2:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: JES2 Spool Data Set Browse (SDSB) sample It sure would be nice to know which suggestion was so awesome > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Chris Cantrell > Sent: Tuesday, August 21, 2018 12:29 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 Spool Data Set Browse (SDSB) sample > > This works awesome! > It is what I ended up using. > Thanks for everyone's comments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Spool Data Set Browse (SDSB) sample
It sure would be nice to know which suggestion was so awesome > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Chris Cantrell > Sent: Tuesday, August 21, 2018 12:29 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 Spool Data Set Browse (SDSB) sample > > This works awesome! > It is what I ended up using. > Thanks for everyone's comments. > > -- > 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: JES2 Spool Data Set Browse (SDSB) sample
This works awesome! It is what I ended up using. Thanks for everyone's comments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
On Tue, 21 Aug 2018 15:07:10 -0400, Phil Smith III wrote: > >Ah, ok, cool. That would be interesting. Not sure how that relates back to the >original problem, which was Skip seeing a "funny" character in a data set. The >emulator would then need to communicate with z/OS about code page in use.gets >pretty messy! > Actually, we're about a third of the way there. If I ISPF View a UNIX file tagged UTF-8 (1208), ISPF converts it for display to the code page of my emulator (TN3270 handshaking presumably tells it). The remaing two thirds is that emulators and 3270 data streams need to be Unicode-savvy. Characters not in the emulator's cabability are transmitted as attribute bytes, but I believe they still appear correctly if I display hex. ISPF needs to do something smarter for hex display of MBCS. More rows for hex? And Find does poorly at placing the cursor. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Anyone here exprerienced in JSON parser (assembler)
Hi ITschak, I’m part of the team that develops the z/OS JSON parser. From your previous post, it appears you have resolved the issue you were experiencing. As you pointed out, we do not provider assembler samples, so you have to connect the dots between the following three things: 1. IBM Knowledge Center, z/OS JSON parser: Description of HWTJ_SEARCHTYPE_GLOBAL that distinguishes between the REXX and non-REXX parameter content: for the first “name” that exactly matches the SearchString for REXX or the string pointed to by the SearchStringAddr parameter for non-REXX. 2. IBM Knowledge Center, z/OS JSON parser: Linkage considerations for assembler language programming that specifies: Register 1 must contain the address of a parameter list that is a list of consecutive words, each containing the address of a parameter to be passed. 3. HWTJIASM macro: HWTJSRCH input parameters section where the HWTJSRCHPARMLIST DSECT shows that these are all pointers to the parameters, in the case of the SearchStringAddr parameter, the DS indicates that this is a pointer to the address: HWTJSRCHSEARCHSTRINGADDRPTRDS A Address of SearchStringAddr Is there additional information that can be added that would have helped more? Or verbiage that should be altered? Galina -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
John McKown wrote: >That's why I want the access method to implement the CCSID conversion, >along with "tagging" and a DD parameter so that the application receives >the data in the code point it is written to handle. I don't want the >application to have to deal with "metadata", but put it on the back of the >access method; most likely QSAM and BSAM and maybe even VSAM. Much like DB2 >can do some of this. Ah, ok, cool. That would be interesting. Not sure how that relates back to the original problem, which was Skip seeing a "funny" character in a data set. The emulator would then need to communicate with z/OS about code page in use.gets pretty messy! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
On Tue, 21 Aug 2018 10:40:56 -0400, Phil Smith III wrote:
>
>>There is one. It's called Unicode. IBM should open its eyes to the 21st
>>Century.
>
>Now that's funny! Sure, we'll just transform all our data from EBCDIC.
>
The slower you peel the adhesive tape, the longer you endure the pain.
On Tue, 21 Aug 2018 17:16:53 +, Seymour J Metz wrote:
>> This whole "tagging" business is a pathetic attempt to cover up two
>> original blunders.
>
>But not the ones that you cite. The original blunders were small byte sizes
>for both ASCII and EBCDIC, leading to a plethora of incompatible extensions of
>both. The answer is Unicode, though perhaps not RFC 8369
>(https://sandbox.ietf.org/doc/rfc8369/ ), but getting there will be
>a bear.
>
When I see something like that, I always check the date, if only to see
how recent it is.
2? 3? 4 and counting?
1) Small byte sizes
To accommodate expensive storage economically.
2)) EBCDIC
To accommodate 7-track tapes economically.
https://web.archive.org/web/20180513204153/http://www.bobbemer.com/P-BIT.HTM
3) Overloading committed code points ("varying code positions" --
http://www.unicode.org/reports/tr16/#Step%201
when plenty uncommited ones were available), impelling
variant code pages.
Economics again. It was cheaper to put gummed labels on key caps
than to rewire the 029 to generate additional codes.
4) Making CP 1047 rather than CP 1208 the convention for UNIX System
services.
How Retro!
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
On Tue, 21 Aug 2018 17:30:36 +, Seymour J Metz wrote: >Be careful what you ask for; you might get it. Unless you tell the access >method how to translate, it likely to trip up the application. Even if you >have both to and from CCSID on the DD statement, > According to the JCL Ref., one goes on the EXEC (what the program processes), the other on the DD (what's on the external medium). I suspect MBCS is unsupported, and it mentions a default of 7-bit ASCII! There are UNIX syscalls to control translation. "od" and "cksum" (e.g.) rely on them. IBM fixed my APAR so they work (FSVO) right. >... there are potential pitfalls. I'd much rather leave the application in >control. Something like DCBE and processing options to specify > >Translate/raw >Application CCID >Query file CCSID >Others I've overlooked > "65535" (Yaay! not "0") in JCL means "raw". I'd expect JCL merge dominance rules to apply. Does filetagging the UNIX Program Object have effect similar to CCSID on the EXEC statement? Only 1047 and 819 are supported by z/OS UNIX. Spool files ought to be taggable. CHARS is some sort of option orthogonal to CCSID. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TESTAUTH BRANCH=XM ?
On 21 August 2018 at 08:23, Peter Relson wrote: > 1) Is BRANCH=XM supported? > Ans: Since it is not in the books, no. That is the stock answer for anything. Yeah, I know... Though there has been the occasional thing that has lacked only the doc, or is documented only in the macro, so worth asking. > If you need this function, then please submit an RFE. It's a would-be-nice. I can program around it. OTOH if it's been there for 15 years, is it really likely to go away? > You can probably get away with checking the JSCBAUTH bit. > There is actually a complex definition of the APF state, and that's what > MODESET checks. > Perhaps someone knows the history behind it. It appears to have allowed > for a lot of future extension that never happened. I do remember some decades ago speculating on the fact that while the linkage editor AC(n) option supports only 0 and 1, the result does go into a one-byte field in the LM/PO. Hints of Multics and multi-level privileges...? > 4) Design-wise, is there a reason that APF authorization of the caller > is not a criterion that can be applied when the PC routine is set up > with ETDEF? > Ans: Yes (for the most part). APF authorization is not a hardware state. > PC's (and things identified by ETDEF, in general) have no way of looking > at software-defined structures. You make a good point. I was thinking that SVCs can be set up in advance to accept or reject non-APF callers, but that of course isn't done by the hardware. And there is no "PC FLIH" analogous to the SVC one. I suppose JSCBAUTH could be copied to some known-to-hardware location, as various formerly software-only things have been over the years. But not in my lifetime, I suspect. Thanks, Peter. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
> This whole "tagging" business is a pathetic attempt to cover up two > original blunders. But not the ones that you cite. The original blunders were small byte sizes for both ASCII and EBCDIC, leading to a plethora of incompatible extensions of both. The answer is Unicode, though perhaps not RFC 8369 (https://sandbox.ietf.org/doc/rfc8369/ ), but getting there will be a bear. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, August 21, 2018 1:03 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Funny characters in CPAC.PARMLIB(HZSPRM00) On Tue, 21 Aug 2018 11:26:39 -0500, John McKown wrote: >On Tue, Aug 21, 2018 at 10:40 AM Phil Smith III wrote: >> >> >I'm not saying how this "tagging" would be implemented. I don't know if >> >there is any room in the VTOC entry for a CCSID. Or if it would require >> >something in the VVDS. And the problem remains for "mixed" data where the >> >records contain both "binary" and "textual" information. >> >> That's an intriguing thought. Of course adding metadata like that to z/OS >> data sets creates a whole new mess, with "Oh, that application/whatever >> doesn't handle the tagging", but once we got there, it sure would make life >> simpler! > It would be easier to define a new attribute to new Program Objects (or relinked ones) that to retroactively tab a legacy of data sets. >That's why I want the access method to implement the CCSID conversion, >along with "tagging" and a DD parameter so that the application receives >the data in the code point it is written to handle. I don't want the >application to have to deal with "metadata", but put it on the back of the >access method; most likely QSAM and BSAM and maybe even VSAM. Much like DB2 >can do some of this. > There are CCSID options on the JCL JOB, EXEC, and DD statements that do some of this. But their function is so restricted as to make them nearly useless. This whole "tagging" business is a pathetic attempt to cover up two original blunders. https://secure-web.cisco.com/1YPcqIdFNsW6vydbKyPrfVOtsuWgu8HFY9x84psPlkom-h-DEsSP2oIlRvb8f6jAkO-UbhvZEVK80Jh1muwsqakoqhuL_u6Y2Nu1oai3YC-TOytdJkyE_pkmh5KrbTMr8GoMw3YBBAdBx-TSvK-buQGjN2hmnTnYX_Ak6CwJS6_D_OsKQasjL1jytMCt4ptHtlCRa8gkaRpYv_qs9VE3dLKGQbpW4ryM1vuGXy9fl9Viq6EJIxW5jv1S0P-lCCrx_vspAzMtB_e_CjaNvGXTIH-ZFUL4DqPLIf_kqp8XqPNQ0xAQvuhsRq2rWqmPaO65s9hRFGUmj6o6hYtNqjAwTmv69lt-FO9d8-528-4L-abvt71n9LNVNKqfNpfl-eIiSG4qAjf2Ad_9nynIrqRTdd830oAQ0AKl-8uX3ugJkssQhzN2qubQ0Nattc38J7kVk/https%3A%2F%2Fweb.archive.org%2Fweb%2F20180513204153%2Fhttp%3A%2F%2Fwww.bobbemer.com%2FP-BIT.HTM -- 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: Funny characters in CPAC.PARMLIB(HZSPRM00)
Be careful what you ask for; you might get it. Unless you tell the access method how to translate, it likely to trip up the application. Even if you have both to and from CCSID on the DD statement, there are potential pitfalls. I'd much rather leave the application in control. Something like DCBE and processing options to specify Translate/raw Application CCID Query file CCSID Others I've overlooked -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of John McKown Sent: Tuesday, August 21, 2018 12:26 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Funny characters in CPAC.PARMLIB(HZSPRM00) On Tue, Aug 21, 2018 at 10:40 AM Phil Smith III wrote: > John McKown wrote: > > >What I, personally, think would be nice is something which exists, > >somewhat, in z/OS UNIX files. That is "file tagging". In z/OS UNIX you can > >"tag" a file's contents to specify that the text in the file is in a > >particular CCSID (code page). What might be nice would be if every piece > of > >data could, optionally, be "tagged" as having a CCSID for the data inside > >it. Of course, this only works when all the data inside is "textual" and > >not "binary". Anyway, tag the data as being in a particular CCSID. Then > >have a parameter on the DD statement which basically indicates the CCSID > >that the program expects its data to be in. If the data doesn't have a > >"tag", assume CP-037 for historical purposes. If the DD doesn't specify a > >CCSID, assume CP-037 too. So in the default case, the CCSIDs would both be > >CP-037 so no translation would be made. I am assuming that the access > >method would do the translation, using Unicode System Services, and would > >not do a conversion if the CCSIDs were identical. If the CCSIDs don't > >match, then the access method would use the Unicode services to do the > >translation on input & output. I am assuming that all members of a PD > S > > >would be in the same CCSID. I guess this could be extended for individual > >members in a PDSE version "2.1" or something. The tagging would be > >automatic if a file is created using JCL or DYNALLOC by using the CCSID > >specified in the DD or DYNALLOC. Again, defaulting to CP-037 for historic > >purposes. > > >I'm not saying how this "tagging" would be implemented. I don't know if > >there is any room in the VTOC entry for a CCSID. Or if it would require > >something in the VVDS. And the problem remains for "mixed" data where the > >records contain both "binary" and "textual" information. > > That's an intriguing thought. Of course adding metadata like that to z/OS > data sets creates a whole new mess, with "Oh, that application/whatever > doesn't handle the tagging", but once we got there, it sure would make life > simpler! > That's why I want the access method to implement the CCSID conversion, along with "tagging" and a DD parameter so that the application receives the data in the code point it is written to handle. I don't want the application to have to deal with "metadata", but put it on the back of the access method; most likely QSAM and BSAM and maybe even VSAM. Much like DB2 can do some of this. -- Between infinite and short there is a big difference. -- G.H. Gonnet Maranatha! <>< John McKown -- 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: TESTAUTH BRANCH=XM ?
On 21 August 2018 at 10:49, Seymour J Metz wrote: > If you only want to test problem state callers, look at the JSCB. Sure... But then why is there a TESTAUTH macro with both SVC and branch entry at all? Everyone could just check JSCBAUTH on their own. And that single bit is even a Programming Interface! Checking key or state is slightly fiddlier from, say, an SVC routine, but still not rocket science. And in a PC routine it's trivial. But I was just wondering why IBM seems to have provided the necessary few lines of code, conveniently located in Common so it can run in home space mode, to do exactly and only this one (JSCBAUTH) test, but not documented it. Providing a PC routine that can handle APF and non-APF callers differently seems like a common enough thing to want to do. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
> Why do URLs that you quote get garbled by secure-web.cisco.com? "The road to Hell is paved with good intensions." It's allegedly a security "feature", and they told me that there's no way to turn it off. They also do it on inbound, and it often breks URLs. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, August 21, 2018 12:46 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Funny characters in CPAC.PARMLIB(HZSPRM00) On Tue, 21 Aug 2018 15:51:57 +, Seymour J Metz wrote: >Close but no cigar. It's an encoding that preserves many of the EBCDIC >characters. > Thereby failing to address the problem that provoked this thread. Why do URLs that you quote get garbled by secure-web.cisco.com? It seems to happen inbound to GMU.EDU. So it protects you from me, but not me from you? Not very charitable. -- 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: Funny characters in CPAC.PARMLIB(HZSPRM00)
On Tue, 21 Aug 2018 11:26:39 -0500, John McKown wrote: >On Tue, Aug 21, 2018 at 10:40 AM Phil Smith III wrote: >> >> >I'm not saying how this "tagging" would be implemented. I don't know if >> >there is any room in the VTOC entry for a CCSID. Or if it would require >> >something in the VVDS. And the problem remains for "mixed" data where the >> >records contain both "binary" and "textual" information. >> >> That's an intriguing thought. Of course adding metadata like that to z/OS >> data sets creates a whole new mess, with "Oh, that application/whatever >> doesn't handle the tagging", but once we got there, it sure would make life >> simpler! > It would be easier to define a new attribute to new Program Objects (or relinked ones) that to retroactively tab a legacy of data sets. >That's why I want the access method to implement the CCSID conversion, >along with "tagging" and a DD parameter so that the application receives >the data in the code point it is written to handle. I don't want the >application to have to deal with "metadata", but put it on the back of the >access method; most likely QSAM and BSAM and maybe even VSAM. Much like DB2 >can do some of this. > There are CCSID options on the JCL JOB, EXEC, and DD statements that do some of this. But their function is so restricted as to make them nearly useless. This whole "tagging" business is a pathetic attempt to cover up two original blunders. https://web.archive.org/web/20180513204153/http://www.bobbemer.com/P-BIT.HTM -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
On Tue, 21 Aug 2018 15:51:57 +, Seymour J Metz wrote: >Close but no cigar. It's an encoding that preserves many of the EBCDIC >characters. > Thereby failing to address the problem that provoked this thread. Why do URLs that you quote get garbled by secure-web.cisco.com? It seems to happen inbound to GMU.EDU. So it protects you from me, but not me from you? Not very charitable. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: StackExchange proposed mainframe discussion group
On Tue, 21 Aug 2018 15:29:47 +, Seymour J Metz wrote: >MVS-OE ha a more restricted scope than IBM-MAIN. You might have a better >chance of your message being seen by a SME if you post it to a more specific >list. On the flip side, you get more eyeballs on a list of broader scope. They >are both useful. > So, cross-post to both? >The same applies to other topics: ISPF, JES2, RACF, REXX and TSO are all >relevant in IBM-MAIN, -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
On Tue, 21 Aug 2018 15:28:02 +, Seymour J Metz wrote: >> There are transforms for EBCDIC code pages to UTF-8 et al. > >Right answer to wrong question. See > >https://en.wikipedia.org/wiki/UTF-EBCDIC > >http://www.unicode.org/reports/tr16/ > Thanks. Ugh! It's sorta IBM-1047 based; certain to displease partisans of 037 and 500. And it supports "13 variant ASCII graphic characters (occupy varying code positions)", probably including the "squirrely" characters. It adds complexity and solves hardly anything. It has not been widely accepted. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
On Tue, Aug 21, 2018 at 10:40 AM Phil Smith III wrote: > John McKown wrote: > > >What I, personally, think would be nice is something which exists, > >somewhat, in z/OS UNIX files. That is "file tagging". In z/OS UNIX you can > >"tag" a file's contents to specify that the text in the file is in a > >particular CCSID (code page). What might be nice would be if every piece > of > >data could, optionally, be "tagged" as having a CCSID for the data inside > >it. Of course, this only works when all the data inside is "textual" and > >not "binary". Anyway, tag the data as being in a particular CCSID. Then > >have a parameter on the DD statement which basically indicates the CCSID > >that the program expects its data to be in. If the data doesn't have a > >"tag", assume CP-037 for historical purposes. If the DD doesn't specify a > >CCSID, assume CP-037 too. So in the default case, the CCSIDs would both be > >CP-037 so no translation would be made. I am assuming that the access > >method would do the translation, using Unicode System Services, and would > >not do a conversion if the CCSIDs were identical. If the CCSIDs don't > >match, then the access method would use the Unicode services to do the > >translation on input & output. I am assuming that all members of a PD > S > > >would be in the same CCSID. I guess this could be extended for individual > >members in a PDSE version "2.1" or something. The tagging would be > >automatic if a file is created using JCL or DYNALLOC by using the CCSID > >specified in the DD or DYNALLOC. Again, defaulting to CP-037 for historic > >purposes. > > >I'm not saying how this "tagging" would be implemented. I don't know if > >there is any room in the VTOC entry for a CCSID. Or if it would require > >something in the VVDS. And the problem remains for "mixed" data where the > >records contain both "binary" and "textual" information. > > That's an intriguing thought. Of course adding metadata like that to z/OS > data sets creates a whole new mess, with "Oh, that application/whatever > doesn't handle the tagging", but once we got there, it sure would make life > simpler! > That's why I want the access method to implement the CCSID conversion, along with "tagging" and a DD parameter so that the application receives the data in the code point it is written to handle. I don't want the application to have to deal with "metadata", but put it on the back of the access method; most likely QSAM and BSAM and maybe even VSAM. Much like DB2 can do some of this. -- Between infinite and short there is a big difference. -- G.H. Gonnet Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
Close but no cigar. It's an encoding that preserves many of the EBCDIC characters. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Tuesday, August 21, 2018 11:39 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Funny characters in CPAC.PARMLIB(HZSPRM00) Seymour J Metz wrote: >Right answer to wrong question. See >https://secure-web.cisco.com/1AjDzY9_E0OiBTbw17ctl9VBw-y-oQEYvbmMuP32v3DCS-ua0IQsEz36s6OqxSAQe-BB-4iEmkD9IyH1VB2KJ2QsE-1kz5OzwFdT41425oI0LuhJ8FNCDBUQEB0OCp42kX6DKOaO9UaYBaWX8DUyiS58WeM4rXIwW5JoesvaYqM1WtAS0hNY6AMmbFrJfjTDcFsQs9nSx6qrb3wDAdBrnqUQFMGRVdr6EDfBhikipm7tpp-T20CHRAXPr6PerE_oc0XpPKeFtTAJFbs8TBrAfL7QVN5vcXOZTR7rUUGpxpYMp9rsocSIs4SMGJ312S3i2HfMQL8IDNSjhmnfcCCcY1h705sWpR5H1r7ZXpgqfCGTt5lhakPVsrj-vclbm2w7jAYJVXA7Lb8iRQirbi2d9wqOlVlDP0ahm-l4RlnfH4nUTBVHkHldF3f4cv2kNGD4R/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FUTF-EBCDIC >http://secure-web.cisco.com/13HAU9OMkaZZ04wEaKMXVwnxfxVjzDEcnC8zxPp2HPlUW2gmGb48yV6R9ihZNQvI46xDUwyNlOYq5mZ74pbSqn04Vgti0q8lqAL3IdAB70-P29nPJmYrPZpmMe35cfBSliZqKVSVCzKln7h6JrYQSWnfO0oMHckfEEyGTrg_wkpQLHAEv_n5-EgTcIPpjzf8GOENWseqj26zpDmf84Gf--pLs7VfPkN6gxfujFlD7QXbp5Sir2r-7XT30TPfYO6KPgYwHT6AdqEkeKoOiKRSrJTL78RZ2KHrYwdPoAB96oG4XuNhgl56NF8LkSPwrhCoMGUbP8-OX3o9EAXoY9t3nYfcLDd_6HSRaMhisSKvTSMJnAL3JWtcCdoH54C4X22o0pbFeSDS4fC9IT1ARQv-WsB_Kbecf9QYqfQPhHW-EaZoTOdIwc6aaZZv4qY-XJFxm/http%3A%2F%2Fwww.unicode.org%2Freports%2Ftr16%2F That's just encoding, doesn't help to tag/identify the data, so no. -- 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: Funny characters in CPAC.PARMLIB(HZSPRM00)
John McKown wrote: >What I, personally, think would be nice is something which exists, >somewhat, in z/OS UNIX files. That is "file tagging". In z/OS UNIX you can >"tag" a file's contents to specify that the text in the file is in a >particular CCSID (code page). What might be nice would be if every piece of >data could, optionally, be "tagged" as having a CCSID for the data inside >it. Of course, this only works when all the data inside is "textual" and >not "binary". Anyway, tag the data as being in a particular CCSID. Then >have a parameter on the DD statement which basically indicates the CCSID >that the program expects its data to be in. If the data doesn't have a >"tag", assume CP-037 for historical purposes. If the DD doesn't specify a >CCSID, assume CP-037 too. So in the default case, the CCSIDs would both be >CP-037 so no translation would be made. I am assuming that the access >method would do the translation, using Unicode System Services, and would >not do a conversion if the CCSIDs were identical. If the CCSIDs don't >match, then the access method would use the Unicode services to do the >translation on input & output. I am assuming that all members of a PDS >would be in the same CCSID. I guess this could be extended for individual >members in a PDSE version "2.1" or something. The tagging would be >automatic if a file is created using JCL or DYNALLOC by using the CCSID >specified in the DD or DYNALLOC. Again, defaulting to CP-037 for historic >purposes. >I'm not saying how this "tagging" would be implemented. I don't know if >there is any room in the VTOC entry for a CCSID. Or if it would require >something in the VVDS. And the problem remains for "mixed" data where the >records contain both "binary" and "textual" information. That's an intriguing thought. Of course adding metadata like that to z/OS data sets creates a whole new mess, with "Oh, that application/whatever doesn't handle the tagging", but once we got there, it sure would make life simpler! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
Seymour J Metz wrote: >Right answer to wrong question. See >https://en.wikipedia.org/wiki/UTF-EBCDIC >http://www.unicode.org/reports/tr16/ That's just encoding, doesn't help to tag/identify the data, so no. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: StackExchange proposed mainframe discussion group
MVS-OE ha a more restricted scope than IBM-MAIN. You might have a better chance
of your message being seen by a SME if you post it to a more specific list. On
the flip side, you get more eyeballs on a list of broader scope. They are both
useful.
The same applies to other topics: ISPF, JES2, RACF, REXX and TSO are all
relevant in IBM-MAIN,
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Charles Mills
Sent: Sunday, August 19, 2018 11:26 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: StackExchange proposed mainframe discussion group
"The archives" are partitioned inconveniently now. MVS-OE is an example all by
itself. How is a z/OS UNIX ("MVS-OE") problem different from a mainframe
("IBM-MAIN") problem? And aren't the IBM-MAIN archives themselves partitioned
into "old" and "new"?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
>
Would this partition the archives inconveniently This week I searched
successfully for a 15-year old article in MVS-OE. Would I lose this
capability?
-- 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: Funny characters in CPAC.PARMLIB(HZSPRM00)
> There are transforms for EBCDIC code pages to UTF-8 et al. Right answer to wrong question. See https://en.wikipedia.org/wiki/UTF-EBCDIC http://www.unicode.org/reports/tr16/ -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Tuesday, August 21, 2018 10:59 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Funny characters in CPAC.PARMLIB(HZSPRM00) Seymour J Metz wrote: >There' an EBCDIC transform for Unicode. Um. There are transforms for EBCDIC code pages to UTF-8 et al. But that's not *the* answer: there's no intrinsic association of data with a given EBCDIC code page, so "Just transform it" is a non-trivial exercise. Once you know what code page it is, it's (relatively) trivial, but you have to get to that point. And if you say "Well, it's all 1047", we already know that won't work, because at least some data may be expecting 037. -- 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: Funny characters in CPAC.PARMLIB(HZSPRM00)
On Tue, Aug 21, 2018 at 9:41 AM Phil Smith III wrote: > Paul Gilmartin wrote: > > >There is one. It's called Unicode. IBM should open its eyes to the 21st > Century. > > Now that's funny! Sure, we'll just transform all our data from EBCDIC. > What I, personally, think would be nice is something which exists, somewhat, in z/OS UNIX files. That is "file tagging". In z/OS UNIX you can "tag" a file's contents to specify that the text in the file is in a particular CCSID (code page). What might be nice would be if every piece of data could, optionally, be "tagged" as having a CCSID for the data inside it. Of course, this only works when all the data inside is "textual" and not "binary". Anyway, tag the data as being in a particular CCSID. Then have a parameter on the DD statement which basically indicates the CCSID that the program expects its data to be in. If the data doesn't have a "tag", assume CP-037 for historical purposes. If the DD doesn't specify a CCSID, assume CP-037 too. So in the default case, the CCSIDs would both be CP-037 so no translation would be made. I am assuming that the access method would do the translation, using Unicode System Services, and would not do a conversion if the CCSIDs were identical. If the CCSIDs don't match, then the access method would use the Unicode services to do the translation on input & output. I am assuming that all members of a PDS would be in the same CCSID. I guess this could be extended for individual members in a PDSE version "2.1" or something. The tagging would be automatic if a file is created using JCL or DYNALLOC by using the CCSID specified in the DD or DYNALLOC. Again, defaulting to CP-037 for historic purposes. I'm not saying how this "tagging" would be implemented. I don't know if there is any room in the VTOC entry for a CCSID. Or if it would require something in the VVDS. And the problem remains for "mixed" data where the records contain both "binary" and "textual" information. -- Between infinite and short there is a big difference. -- G.H. Gonnet Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
Seymour J Metz wrote: >There' an EBCDIC transform for Unicode. Um. There are transforms for EBCDIC code pages to UTF-8 et al. But that's not *the* answer: there's no intrinsic association of data with a given EBCDIC code page, so "Just transform it" is a non-trivial exercise. Once you know what code page it is, it's (relatively) trivial, but you have to get to that point. And if you say "Well, it's all 1047", we already know that won't work, because at least some data may be expecting 037. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TESTAUTH BRANCH=XM ?
If you only want to test problem state callers, look at the JSCB. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tony Harminc Sent: Monday, August 20, 2018 10:15 PM To: IBM-MAIN@listserv.ua.edu Subject: TESTAUTH BRANCH=XM ? (I'm speaking of the MVS macro, and not the TSO command.) BRANCH=XM appears to be undocumented, though it's been in the macro for 15 years. It seems to surround the function of TESTAUTH FCTN=1 with a change to home space mode and back, so that presumably relevant MVS control blocks such as the JSCB are accessible. 1) Is BRANCH=XM supported? (In passing, the doc says that "Only SVC routines can use BRANCH=YES." Is that true?) 2) The description of TESTAUTH says it requires entry in Primary mode with PASN-HASN-SASN. Is *that* true? 3) What is the official way for a SS PC routine to find out if the issuer of the PC is running in an APF authorized environment? (I am aware that that caller could be in SRB mode or otherwise not be in a state conducive to answering the question, but presumably one would care only if the caller is in a user key and problem state.) 4) Design-wise, is there a reason that APF authorization of the caller is not a criterion that can be applied when the PC routine is set up with ETDEF? Thanks! 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: Funny characters in CPAC.PARMLIB(HZSPRM00)
There' an EBCDIC transform for Unicode. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Tuesday, August 21, 2018 10:40 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Funny characters in CPAC.PARMLIB(HZSPRM00) Paul Gilmartin wrote: >There is one. It's called Unicode. IBM should open its eyes to the 21st >Century. Now that's funny! Sure, we'll just transform all our data from EBCDIC. -- 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: Funny characters in CPAC.PARMLIB(HZSPRM00)
Paul Gilmartin wrote: >There is one. It's called Unicode. IBM should open its eyes to the 21st >Century. Now that's funny! Sure, we'll just transform all our data from EBCDIC. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem with RECEIVE ORDER Servers - Fixed
I'm told both servers are back up now. (The cause was an inter-server communications failure on our side.) -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using the Binder API and MetalC
Strictly as a circumvention, knowing that you are not actually going to call these functions, I want to make sure you know you could use the XL C/C++ SUPPRESS option: SUPPRESS(CCN3244) On 16 Aug 2018 16:24:56 + Farley, Peter x23353 wrote: > Yes the binder API header as coded does cause harm when included in a MetalC > program. > Below is the result of including the binder API header as provided by IBM: > > ERROR CCN3244 /usr/include/__iew_api.h:659 External variable __IEW_GE > cannot be redefined. > . . . > ERROR CCN3244 /usr/include/__iew_api.h:530 External variable __IEW_AD > cannot be redefined. > CCN0793(I) Compilation failed for file //'TSOUSER.TEST.CSRC(TESTBIND)'. > Object file not created. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
On Tue, 21 Aug 2018 09:17:50 -0400, Tom Conley wrote: >On 8/21/2018 9:03 AM, Peter Relson wrote: >> These were changed in z/OS 2.3 to x'AD' / x'BD' >> >> E.g., >> HZSPDATA=dsn[,VOLUME=volser] > >Ah, > >So that's why I have to flip back and forth now between 3 and 6 for my >IBM terminal types. Thanks for the explanation Peter. Maybe someday we >can get a consistent character set for square brackets. > There is one. It's called Unicode. IBM should open its eyes to the 21st Century. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
On 8/21/2018 9:03 AM, Peter Relson wrote: These were changed in z/OS 2.3 to x'AD' / x'BD' E.g., HZSPDATA=dsn[,VOLUME=volser] Peter Relson z/OS Core Technology Design Ah, So that's why I have to flip back and forth now between 3 and 6 for my IBM terminal types. Thanks for the explanation Peter. Maybe someday we can get a consistent character set for square brackets. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Announcing New DS8882F Enterprise Storage
Does anyone know how the HMC will be handled for this unit? Will it be a customer provided pc like the old 6800? Is the z14 HMC in the rack going to be usable to manage it? Tony Thigpen Timothy Sipples wrote on 08/21/2018 12:14 AM: I'd like to draw your attention to a new, high performance IBM Z and IBM LinuxONE attachable storage system: the IBM DS8882F. Details here: https://developer.ibm.com/storage/2018/08/13/new-ds8882f-big-value-smaller-package/ The DS8882F is a full fledged member of the IBM DS8880 series, with the same architecture (including software/firmware foundation), features, and resiliency. However, it's designed to install within a standard 19 inch rack and to require only 16U of rack space. That means the DS8882F can be installed within the IBM z14 ZR1 and IBM LinuxONE Rockhopper II frame, for a single footprint machine plus storage solution. (It doesn't have to be, though. You have full multi-system/multi-type and physical installation flexibility, with both FICON/ECKD and FCP/FBA support.) Like the other members of the IBM DS8880 family, the IBM DS8882F supports Cloud Object Storage with z/OS DFSMShsm, called "Transparent Cloud Tiering." On premises and/or off premises cloud-compliant storage can be used as another HSM storage tier, automatically staged/de-staged. Details here: http://www.redbooks.ibm.com/redbooks/pdfs/sg248381.pdf The DS8882F is an all flash design for high performance, with up to 358.4TB of raw capacity. Storage level encryption is supported, of course. (Did I mention it's a full fledged DS8880 system?) For a few years now I've/we've been looking/waiting for a smaller form factor mainframe storage system as the spiritual successor to the IBM DS6800. Spiritual only, though, because I really want to have the full feature set available with the same design approach, just in a smaller form factor and still with a healthy amount of storage capacity (up to 300+ TB usable). Now it's here, and it's great to see this choice, IMHO. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
These were changed in z/OS 2.3 to x'AD' / x'BD' E.g., HZSPDATA=dsn[,VOLUME=volser] 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
Problem with RECEIVE ORDER Servers
A problem has been identified with the RECEIVE ORDER servers (both of them, unfortunately), and people are working on a fix. When I have more information, I will let you all know. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CD 5.1.1 and CE 1.4
Hi All, Need one help with respect to Sterling connect direct and connnect Enterprise for zos I'm running 5.1.1 CD and 1.4 CE with z/OS 2.1, and I'm planning to upgrade z/OS 2.3, does CD 5.1.1 & CE 1.4 is compatible with z/OS 2.3? As we know 5.1.1& 1.4 already out of support and I don't have extended support either. Need some suggestion. Thanks Regards, Shashi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TESTAUTH BRANCH=XM ?
1) Is BRANCH=XM supported? Ans: Since it is not in the books, no. That is the stock answer for anything. If you need this function, then please submit an RFE. (In passing, the doc says that "Only SVC routines can use BRANCH=YES." Is that true?) Ans: I suppose "yes" if checking state and/or key but not if checking only APF authorization. The information about the caller's state and/or key applies only when this is an SVC routine because it is examining data in an identified RB (not in a linkage stack entry). 2) The description of TESTAUTH says it requires entry in Primary mode with PASN-HASN-SASN. Is *that* true? Ans: Yes. If BRANCH=XM were supported, the answer would be "except when BRANCH=XM". 3) What is the official way for a SS PC routine to find out if the issuer of the PC is running in an APF authorized environment? (I am aware that that caller could be in SRB mode or otherwise not be in a state conducive to answering the question, but presumably one would care only if the caller is in a user key and problem state.) Ans: Many PC routines choose not to accept APF authorization. You can probably get away with checking the JSCBAUTH bit. There is actually a complex definition of the APF state, and that's what MODESET checks. Perhaps someone knows the history behind it. It appears to have allowed for a lot of future extension that never happened. 4) Design-wise, is there a reason that APF authorization of the caller is not a criterion that can be applied when the PC routine is set up with ETDEF? Ans: Yes (for the most part). APF authorization is not a hardware state. PC's (and things identified by ETDEF, in general) have no way of looking at software-defined structures. The things in ETDEF related to ARRs are the exception, but there RTM goes through a lot of machinations to locate the information in order to figure out what has been specified. And it could not be "enforced" on the PC itself (which I think is what your question is getting at)/ Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Searching the archives.
Hi, Search is not working for me. Until this is figured out you can go from https://listserv.ua.edu/archives/ibm-main.html to each month separately and on the selected month table of content key (CTRL +F) and in the popup box key "system s" ... It appears in months May, June and August. In July there are "system sysmbols" (not system symbols ...) :) Be Happy☺ On Tue, 21 Aug 2018 at 10:02, Vernooij, Kees (ITOPT1) - KLM < kees.verno...@klm.com> wrote: > From https://listserv.ua.edu/archives/ibm-main.html I select "Search the > archives" and search for "system symbols" since "1 jan 2018". This has no > results. > > Playing around with other search options and screens reveils old articles. > It did work well earlier this year. > > Kees. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Lizette Koehler > > Sent: 20 August, 2018 18:50 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Searching the archives. > > > > Which URL are you using? There are two and one is for a much older > > archive. > > > > Could you show us your search keywords and where you are entering them? > > > > > > > > General MVS IBM-Main https://listserv.ua.edu/archives/ibm-main.html > > > > > > > > IBM-MAIN Archives 1986-2004 (834 Subscribers) > > > > https://listserv.ua.edu/cgi-bin/wa?A0=IBM-MAIN-ARCHIVES > > > > > > Lizette > > > > > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List On > > Behalf Of > > > Vernooij, Kees (ITOPT1) - KLM > > > Sent: Monday, August 20, 2018 5:56 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Searching the archives. > > > > > > Hello, > > > > > > I try to look up a subject from a few months ago in the Archives, but > > all the > > > searchoptions return matches from sometimes 2005 and older, sometimes > > 2009 > > > and older. Nothing from this year. > > > How do I Search the Archives? > > > > > > Kees. > > > > > > > > > For information, services and offers, please visit our web site: > > > http://www.klm.com. This e-mail and any attachment may contain > > confidential > > > and privileged material intended for the addressee only. If you are > > not the > > > addressee, you are notified that no part of the e-mail or any > > attachment may > > > be disclosed, copied or distributed, and that any other action related > > to > > > this e-mail or attachment is strictly prohibited, and may be unlawful. > > If you > > > have received this e-mail by error, please notify the sender > > immediately by > > > return e-mail, and delete this message. > > > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > > its > > > employees shall not be liable for the incorrect or incomplete > > transmission of > > > this e-mail or any attachments, nor responsible for any delay in > > receipt. > > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > Dutch > > > Airlines) is registered in Amstelveen, The Netherlands, with > > registered > > > number 33014286 > > > > > > > > > -- > > > 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 information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. If > you are not the addressee, you are notified that no part of the e-mail or > any attachment may be disclosed, copied or distributed, and that any other > action related to this e-mail or attachment is strictly prohibited, and may > be unlawful. If you have received this e-mail by error, please notify the > sender immediately by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission > of this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >
Re: Searching the archives.
>From https://listserv.ua.edu/archives/ibm-main.html I select "Search the >archives" and search for "system symbols" since "1 jan 2018". This has no >results. Playing around with other search options and screens reveils old articles. It did work well earlier this year. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: 20 August, 2018 18:50 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Searching the archives. > > Which URL are you using? There are two and one is for a much older > archive. > > Could you show us your search keywords and where you are entering them? > > > > General MVS IBM-Main https://listserv.ua.edu/archives/ibm-main.html > > > > IBM-MAIN Archives 1986-2004 (834 Subscribers) > > https://listserv.ua.edu/cgi-bin/wa?A0=IBM-MAIN-ARCHIVES > > > Lizette > > > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of > > Vernooij, Kees (ITOPT1) - KLM > > Sent: Monday, August 20, 2018 5:56 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Searching the archives. > > > > Hello, > > > > I try to look up a subject from a few months ago in the Archives, but > all the > > searchoptions return matches from sometimes 2005 and older, sometimes > 2009 > > and older. Nothing from this year. > > How do I Search the Archives? > > > > Kees. > > > > > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > confidential > > and privileged material intended for the addressee only. If you are > not the > > addressee, you are notified that no part of the e-mail or any > attachment may > > be disclosed, copied or distributed, and that any other action related > to > > this e-mail or attachment is strictly prohibited, and may be unlawful. > If you > > have received this e-mail by error, please notify the sender > immediately by > > return e-mail, and delete this message. > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > its > > employees shall not be liable for the incorrect or incomplete > transmission of > > this e-mail or any attachments, nor responsible for any delay in > receipt. > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch > > Airlines) is registered in Amstelveen, The Netherlands, with > registered > > number 33014286 > > > > > > -- > > 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Searching the archives.
>From https://listserv.ua.edu/archives/ibm-main.html I select "Search the >archives" and search for "system symbols" since "1 jan 2018". It did work well earlier this year. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: 20 August, 2018 18:50 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Searching the archives. > > Which URL are you using? There are two and one is for a much older > archive. > > Could you show us your search keywords and where you are entering them? > > > > General MVS IBM-Main https://listserv.ua.edu/archives/ibm-main.html > > > > IBM-MAIN Archives 1986-2004 (834 Subscribers) > > https://listserv.ua.edu/cgi-bin/wa?A0=IBM-MAIN-ARCHIVES > > > Lizette > > > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of > > Vernooij, Kees (ITOPT1) - KLM > > Sent: Monday, August 20, 2018 5:56 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Searching the archives. > > > > Hello, > > > > I try to look up a subject from a few months ago in the Archives, but > all the > > searchoptions return matches from sometimes 2005 and older, sometimes > 2009 > > and older. Nothing from this year. > > How do I Search the Archives? > > > > Kees. > > > > > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > confidential > > and privileged material intended for the addressee only. If you are > not the > > addressee, you are notified that no part of the e-mail or any > attachment may > > be disclosed, copied or distributed, and that any other action related > to > > this e-mail or attachment is strictly prohibited, and may be unlawful. > If you > > have received this e-mail by error, please notify the sender > immediately by > > return e-mail, and delete this message. > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > its > > employees shall not be liable for the incorrect or incomplete > transmission of > > this e-mail or any attachments, nor responsible for any delay in > receipt. > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch > > Airlines) is registered in Amstelveen, The Netherlands, with > registered > > number 33014286 > > > > > > -- > > 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
