BPXWDYN - Bug or no bug ?
These days we are opting for BPXWDYN in our REXXs instead of TSO ALLOC. One
of the main reason for the switch is BPXWDYN's ability to return the DDNAME
it allocated via the RTDDN parameter.
Chasing down a bug in my code lead me to discover an idiosyncrasy with
BPXWDYN that I think is a bug, but maybe not. So I'm seeking your opinions.
If I have the following
Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"
Say 'DDname allocated is 'dd
Call bpxwdyn "Free fi("dd")"
Running this exec gives something like "DDname allocated is SYS00746"
However, if any.dataset.name is already allocated to an alternate DDNAME
that is not in concatenation then, instead of allocating a new DDname it
just returns the DDNAME of the existing allocation.
You can see this with this code
Address tso "alloc fi(abug) da('any.dataset.name') shr resue"
Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"
Say 'DDname allocated is 'dd
Call bpxwdyn "Free fi("dd")"
And you will get "DDname allocated is ABUG"
Problem is because I'm not getting a new allocation my FREE is freeing up a
DDNAME allocated by a totally different process. In my case causing an
abend sometime later because a DDname that should be allocated is not.
This doesn't seem right to me. An "ALLOC" should do a new allocation every
time.
Comments
Gary Freestone
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS dataset oddity with COM-Plete
On Feb 19, 2018, at 1:01 AM, Brian Westerman wrote: > > Changing SWA and keeping the UCB below the line had not effect, the problem > still exists. Have you examined *UDUMP to try to figure out what it’s trying to do when the ABEND occurs? -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
You need to set flag "S99NOCNV Do not use an existing allocation to satisfy this request." But I don't know if BPXWDYN allows this. Depends on what you call a bug... DYNALLOC itself has driven me crazy with all the various flags and options trying to figure out "convertible", etc. sas On Mon, Feb 19, 2018 at 8:18 AM, Gary Freestone wrote: > ... > Comments > > This doesn't seem right to me. An "ALLOC" should do a new allocation every > time. > > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
Phil/Gil: Correct, sorry been a week, CP285 is a UK EBCDIC codepage. But my question still stands ... 1. PC/Linux -> sends ascii encrypted data to IBM z/OS , like I mentioned a STC in Cobol 2. The STC decrypts and then converts to EBCDIC... My issue is CAN i query a codepage or CCSID on z/OS to find out what the customer is using without a parameter of some sort. Regards, On Sun, Feb 18, 2018 at 8:34 PM, Mike Schwab wrote: > Knowing what country the data is coming from would greatly reduce the > possibilities to one or a handful of code pages. > > On Sun, Feb 18, 2018 at 3:40 PM, Phil Smith III wrote: > > scott Ford wrote, in part: > > > >>The ASCII is CP 285 UK ..but we have to support all .I am making sure I > > > > > > > > That's not ASCII. This is the point others have been making: you can't > > really say "ASCII" unless you mean x'00' through x'127' *and nothing > else*: > > all you can say is "It's not EBCDIC". Once you start talking other "code > > pages", you either need to know which it is, or you have to make an > > assumption. Period. > > > > > > > > And from my reading, code page 285 is an EBCDIC code page. > > > > > > > > Sorry to sound like a hardass about this, but I'm not sure your question > has > > a meaningful answer, based on what you've said so far. > > > > > > > > .phsiii > > > > > > -- > > 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 > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
Gary, What are you trying to do in the Rexx program/clist ? Scott On Mon, Feb 19, 2018 at 8:46 AM, Steve Smith wrote: > You need to set flag "S99NOCNV Do not use an existing allocation to satisfy > this request." But I don't know if BPXWDYN allows this. > > Depends on what you call a bug... DYNALLOC itself has driven me crazy with > all the various flags and options trying to figure out "convertible", etc. > > sas > > On Mon, Feb 19, 2018 at 8:18 AM, Gary Freestone > wrote: > > > ... > > > Comments > > > > This doesn't seem right to me. An "ALLOC" should do a new allocation > every > > time. > > > > > -- > sas > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS dataset oddity with COM-Plete
I would get a dump, logrec, syslog and open an issue with IBM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
On Mon, Feb 19, 2018 at 8:08 AM, scott Ford wrote: > Phil/Gil: > > Correct, sorry been a week, CP285 is a UK EBCDIC codepage. > But my question still stands ... > > 1. PC/Linux -> sends ascii encrypted data to IBM z/OS , like I mentioned a > STC in Cobol > 2. The STC decrypts and then converts to EBCDIC... > > My issue is CAN i query a codepage or CCSID on z/OS to find out what the > customer is using without a parameter of some sort. > > Regards, > > In general, no. If you can communicate with the far end, you might be able to ask the software on the user's machine "what is your locale?" and have it reply. But there is nothing in the TCPIP connection that I am aware of which encodes the end user's locale information. -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
HMC log question
Hello Group, It seems a simple question, but we can't find it: Does the z13s HMC log when a disabled waitstate is loaded and how can I access the log? Or is the only way to find out about these event to email them via the Monitor System Events function? 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
Re: HMC log question
HARDWARE messages should have that info. Might be LPAR specific. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: Monday, February 19, 2018 9:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: HMC log question Hello Group, It seems a simple question, but we can't find it: Does the z13s HMC log when a disabled waitstate is loaded and how can I access the log? Or is the only way to find out about these event to email them via the Monitor System Events function? Kees. For information, services and offers, please visit our web site: https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.com&data=02%7C01%7Callan.staller%40HCL.COM%7C1aaca43f56734effc1a908d577acb1ec%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636546505997956677&sdata=pdmwL2OcRjuinH%2BVXdU3lswU0eyWmOeBV544bEc0yDw%3D&reserved=0. 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 ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
Hi Scot. It appears that EZACIE2A and EZACIA2E are aliases for EZACICTR.A, which is described in http://www-01.ibm.com/support/docview.wss?uid=swg21256665 This isn't really a COBOL answer, but it seems to me you could replace the table names in EZACICTR from "US", "CANADIAN", "DUTCH"... to the codepage names supplied in the comments: TRFIRST DS0A DCCL8'AUSGER',A(AUSGER) Austrian/German CECP 273 DCCL8'BELGIAN',A(BELGIAN) Belgian (New) CECP 500 DCCL8'CANADIAN',A(CANADIAN) Canadian Bilingual CECP 037 ... DCCL8'TELNETSE',A(TELNETSE) DCCL8'UK',A(UK) English (UK) CECP 285 DCCL8'US',A(US) English (US) CECP 037 TRENDEQU * This doesn't help identify the codepage, but when you have it, it would allow you to pass the codepage number instead of the table name. It also appears that EZACICTR allows you to pass a complete table instead of the table name, if that would somehow be easier: * *** * * MULTIPLE mode calls * *** * MOVE 'US' to TABLE-NAME. * CALL 'EZACIE2A' USING OUT-BUFFER LENGTH TABLE-NAME * RETURNING RET-CODE. * CALL 'EZACIA2E' USING OUT-BUFFER LENGTH TABLE-NAME * RETURNING RET-CODE. * * *** * * Optional call valid for either mode * *** * CALL 'EZACICTR' USING OUT-BUFFER LENGTH TRANSLATE-TABLE * RETURNING RET-CODE. hth, Wendell Lovewell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMC log question
We thought so too, but the lists are all empty. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Allan Staller > Sent: 19 February, 2018 16:30 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: HMC log question > > HARDWARE messages should have that info. Might be LPAR specific. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Vernooij, Kees (ITOPT1) - KLM > Sent: Monday, February 19, 2018 9:22 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: HMC log question > > Hello Group, > > It seems a simple question, but we can't find it: > Does the z13s HMC log when a disabled waitstate is loaded and how can I > access the log? > > Or is the only way to find out about these event to email them via the > Monitor System Events function? > > Kees. > > > For information, services and offers, please visit our web site: > https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kl > m.com&data=02%7C01%7Callan.staller%40HCL.COM%7C1aaca43f56734effc1a908d57 > 7acb1ec%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636546505997956677& > sdata=pdmwL2OcRjuinH%2BVXdU3lswU0eyWmOeBV544bEc0yDw%3D&reserved=0. 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 > ::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 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 Ma
Re: HMC log question
There is another service log (don't know how to find it) that also tracks that info. HTH, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Monday, February 19, 2018 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HMC log question HARDWARE messages should have that info. Might be LPAR specific. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: Monday, February 19, 2018 9:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: HMC log question Hello Group, It seems a simple question, but we can't find it: Does the z13s HMC log when a disabled waitstate is loaded and how can I access the log? Or is the only way to find out about these event to email them via the Monitor System Events function? Kees. For information, services and offers, please visit our web site: https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.com&data=02%7C01%7Callan.staller%40HCL.COM%7C1aaca43f56734effc1a908d577acb1ec%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636546505997956677&sdata=pdmwL2OcRjuinH%2BVXdU3lswU0eyWmOeBV544bEc0yDw%3D&reserved=0. 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 ::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: BPXWDYN - Bug or no bug ?
I don't believe there is a way you can force BPXWDYN to do this.
What you can try is check the DDNAME for SYSn, though if you are running
split screen
Another option is to force a DDNAME (perhaps Zhhmmsst?)
On Tue, 20 Feb 2018 00:18:13 +1100 Gary Freestone wrote:
:>These days we are opting for BPXWDYN in our REXXs instead of TSO ALLOC. One
:>of the main reason for the switch is BPXWDYN's ability to return the DDNAME
:>it allocated via the RTDDN parameter.
:>
:>
:>
:>Chasing down a bug in my code lead me to discover an idiosyncrasy with
:>BPXWDYN that I think is a bug, but maybe not. So I'm seeking your opinions.
:>
:>
:>
:>If I have the following
:>
:>
:>
:>
:>
:>Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"
:>
:>Say 'DDname allocated is 'dd
:>
:>Call bpxwdyn "Free fi("dd")"
:>
:>Running this exec gives something like "DDname allocated is SYS00746"
:>
:>However, if any.dataset.name is already allocated to an alternate DDNAME
:>that is not in concatenation then, instead of allocating a new DDname it
:>just returns the DDNAME of the existing allocation.
:>
:>You can see this with this code
:>
:>Address tso "alloc fi(abug) da('any.dataset.name') shr resue"
:>
:>Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"
:>
:>Say 'DDname allocated is 'dd
:>
:>Call bpxwdyn "Free fi("dd")"
:>
:>And you will get "DDname allocated is ABUG"
:>
:>Problem is because I'm not getting a new allocation my FREE is freeing up a
:>DDNAME allocated by a totally different process. In my case causing an
:>abend sometime later because a DDname that should be allocated is not.
:>
:>This doesn't seem right to me. An "ALLOC" should do a new allocation every
:>time.
:>
:>
:>
:>Comments
:>
:>
:>
:>
:>
:>Gary Freestone
:>
:>
:>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Binyamin Dissen
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
On Mon, 19 Feb 2018 08:46:50 -0500, Steve Smith wrote: >You need to set flag "S99NOCNV Do not use an existing allocation to satisfy >this request." But I don't know if BPXWDYN allows this. > I thought such an option was added to BPXWDYN several years ago, but I can't find it in the Ref. I thought that BPXWDN lately supports a recherché facility for supplying an arbitrary TU, but I can't find it in the Ref. It's not my day. Ask about BPXWDYN S99NOCNV in MVS-OE. Someone there knows. >Depends on what you call a bug... DYNALLOC itself has driven me crazy with >all the various flags and options trying to figure out "convertible", etc. > I suspect some of these were desperate attempts to improve performance in the Bad Old Days. Same as lazy "VARY OFFLINE". Why is special authorization needed to mount a virtual tape? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
On Mon, Feb 19, 2018 at 7:04 AM, Gary Freestone wrote:
> These days we are opting for BPXWDYN in our REXXs instead of TSO ALLOC.
> One
> of the main reason for the switch is BPXWDYN's ability to return the DDNAME
> it allocated via the RTDDN parameter.
>
>
>
> Chasing down a bug in my code lead me to discover an idiosyncrasy with
> BPXWDYN that I think is a bug, but maybe not. So I'm seeking your opinions.
>
I think this is normal for SVC 99 (DYNALLOC).
>
> If I have the following
>
>
> Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"
>
> Say 'DDname allocated is 'dd
>
> Call bpxwdyn "Free fi("dd")"
>
Hum, what I would try is to add the "CLOSE" parameter in the BPXWDYN
parameter list. The "CLOSE" parameter is not accepted on z/OS 1.12, but is
on z/OS 2.3. And, on z/OS 2.3, this results in the second BPXWDYN getting a
different DD name.
REXX program:
/* REXX */
TRACE I
CALL BPXWDYN "ALLOC FI(MACLIB) DSN('SYS1.MACLIB') SHR REUSE"
SAY "RC1="RC
CALL BPXWDYN "ALLOC RTDDN(DD1) DSN('SYS1.MACLIB') SHR REUSE CLOSE"
SAY "RC2="RC
SAY "DD1="DD1
CALL BPXWDYN "ALLOC RTDDN(DD2) DSN('SYS1.MACLIB') SHR REUSE CLOSE"
SAY "RC3="RC
SAY "DD2="DD2
In the above, the DD1 & DD2 had _different_ SYSn values.
>
>
>
> Running this exec gives something like "DDname allocated is SYS00746"
>
>
>
> However, if any.dataset.name is already allocated to an alternate DDNAME
> that is not in concatenation then, instead of allocating a new DDname it
> just returns the DDNAME of the existing allocation.
>
> You can see this with this code
>
>
>
> Address tso "alloc fi(abug) da('any.dataset.name') shr resue"
>
> Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"
>
> Say 'DDname allocated is 'dd
>
> Call bpxwdyn "Free fi("dd")"
>
> And you will get "DDname allocated is ABUG"
>
>
>
> Problem is because I'm not getting a new allocation my FREE is freeing up a
> DDNAME allocated by a totally different process. In my case causing an
> abend sometime later because a DDname that should be allocated is not.
>
>
>
> This doesn't seem right to me. An "ALLOC" should do a new allocation every
> time. Comments
>
>
>
> Gary Freestone
>
>
>
>
>
>
>
--
I have a theory that it's impossible to prove anything, but I can't prove
it.
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RECEIVE ORDER down?
All of our RECEIVE ORDERs are getting GIM37150S THE KEYWORD IS MISSING OR INVALID. I've opened a Sev 1 PMR with IBM. Anybody else seen this and know how to fix it? 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: RECEIVE ORDER down?
On 2/19/2018 12:40 PM, Pinnacle wrote: All of our RECEIVE ORDERs are getting GIM37150S THE KEYWORD IS MISSING OR INVALID. I've opened a Sev 1 PMR with IBM. Anybody else seen this and know how to fix it? Regards, Tom Conley Just got word back from IBM. There's a problem with database replication that the server owners are working on foot>. 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: Cobol EBCDIC to ASCII
On Sun, 18 Feb 2018 13:59:37 -0600, Paul Gilmartin wrote:
>I believe "ASCII" can properly be used to refer to the first 128 characters in
>CCSID 819.
>including special characters. Informally, many use "ASCII" to refer to CCSID
>819 or
>other ISO-LATIN code pages.
I've been doing code page and translation table development and analysis since
about 1987. The term "ASCII" is just as ambiguous as "EBCDIC", as without
qualification each term only sets an expectation for the 8-bit encoding of a
somewhat vague set of glyphs.
The original 7-bit ASCII established a full 95-glyph character set that remains
invariant today among all 8-bit ASCII code pages. EBCDIC wasn't quite so
lucky, as it has only 56 invariant characters. It would be 82, but lower case
a-z can vary or be non-existent. If your data is composed of only the 56
common invariant characters, any EBCDIC and ASCII code page will suffice. All
"Latin" EBCDIC code pages will work for lower case a-z.
Here are the common invariant characters.
A-Z
0-9
space
. , + - / * ( ) < > = % : ; _ ? ' " &
If you also have:
@ ! ~ # $ ^ | [ ] { } `
then any ASCII code page will do, but you need to select your EBCDIC code page
carefully.
If you have any other glyph, then both ASCII and EBCDIC code pages must be
selected with care.
Alan Altmark
IBM Lab Services
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
For whatever its worth, once you determine what "ASCII" code page the source is in and what EBCDIC code page you want the result in you can use Enterprise COBOL native intrinsic functions to perform the conversion. Let's assume(!) that the source code page is just the basic Latin-1/ISO-8859-1 (IBM CCSID 819) and the EBCDIC code page is U.K. Latin-1 (CCSID 285)... MOVE FUNCTION DISPLAY-OF ( FUNCTION NATIONAL-OF (ASCII-IN, 819) , 285 ) TO EBCDIC-OUT The "inner function" converts from ASCII CCSID 819 to UTF-16, and the outer function converts from UTF-16 to EBCDIC CCSID 285. This doesn't, of course, answer the question of what the source code page is. They either need to tell you or it needs to be provided as part of the protocol. Frank From: IBM Mainframe Discussion List on behalf of Wendell Lovewell Sent: Monday, February 19, 2018 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol EBCDIC to ASCII Hi Scot. It appears that EZACIE2A and EZACIA2E are aliases for EZACICTR.A, which is described in http://www-01.ibm.com/support/docview.wss?uid=swg21256665 This isn't really a COBOL answer, but it seems to me you could replace the table names in EZACICTR from "US", "CANADIAN", "DUTCH"... to the codepage names supplied in the comments: TRFIRST DS0A DCCL8'AUSGER',A(AUSGER) Austrian/German CECP 273 DCCL8'BELGIAN',A(BELGIAN) Belgian (New) CECP 500 DCCL8'CANADIAN',A(CANADIAN) Canadian Bilingual CECP 037 ... DCCL8'TELNETSE',A(TELNETSE) DCCL8'UK',A(UK) English (UK) CECP 285 DCCL8'US',A(US) English (US) CECP 037 TRENDEQU * This doesn't help identify the codepage, but when you have it, it would allow you to pass the codepage number instead of the table name. It also appears that EZACICTR allows you to pass a complete table instead of the table name, if that would somehow be easier: * *** * * MULTIPLE mode calls * *** * MOVE 'US' to TABLE-NAME. * CALL 'EZACIE2A' USING OUT-BUFFER LENGTH TABLE-NAME * RETURNING RET-CODE. * CALL 'EZACIA2E' USING OUT-BUFFER LENGTH TABLE-NAME * RETURNING RET-CODE. * * *** * * Optional call valid for either mode * *** * CALL 'EZACICTR' USING OUT-BUFFER LENGTH TRANSLATE-TABLE * RETURNING RET-CODE. hth, Wendell Lovewell -- 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
EMPTYTST postscript and thanks
Hi Folks, I was very heartened by the response to my previous post about our writing the EMPTYTST program (CBT Tape File 971 on the Updates page, www.cbttape.org). This is a batch program which was designed to run in a jobstream where some data in a dataset may, or may not, have been produced by a previous job step. And you now want to test that dataset to see whether any data is really there, or whether the dataset is actually empty. The EMPTYTST program, as it now is, produces the following return codes: RETURNS CODE = 0 IF DATASET IS NOT EMPTY. RETURNS CODE = 4 IF DATASET IS EMPTY. JCL ERROR IF A SEQUENTIAL DATASET (DSORG=PS) DOES NOT EXIST. RETURNS CODE = 8 IF PDS MEMBER DOES NOT EXIST. RETURNS CODE = 12 IF SYSUT1 DDNAME IS MISSING. RETURNS CODE = 16 IF SYSUT1 POINTS TO A DATASET CONCATENATION. Much of this action, which the EMPTYTST program now performs, was suggested by readers of this forum, and that is why I am writing this note, to give them the credit that is due them, and to thank the readers of this list in general, for being interested. I want to thank Sri Kolusu of IBM (DFSORT development), for letting us know (in a private email) that the program might be confused if the SYSUT1 DDNAME (the input file) is a concatenation. Really, we only want to be concerned with a single dataset, if data was produced in it or not. A concatenation would confuse and muddle the issue. If, for example, one jobstep produced two datasets to check, we could have two EMPTYTST steps after that in the jobstream, one checking each dataset separately, and each step producing the appropriate return code. Thank you, Sri. Because of you, the program now checks for a concatenation, and produces a severe error (code 16) if there is one. I want to thank one of the dear readers of this forum, who took it upon himself to dig into the EMPTYTST source code, as a result of my post. His name is clearly mentioned in the file (thank you Gerhard). He produced a much-improved program that took care of quite a few deficiencies, adding several hundred lines of code. Upon further testing, we still found a few flaws, so this person teamed up with the original author to have "both pairs of eyes" on the program, and to clear up even more problems. Finally, I stepped in and added a description of all of their improvements, to the program documentation and to the help file. All of this stuff, came about directly as a result of my previous post regarding the EMPTYTST program on this forum. So you see, that besides being useful for answering people's questions, this forum also contributes directly to the quality of software which is being made available for the public's use. (Of course, all disclaimers apply.) Thanks to all of you, folks All the best of everything to all of you. Sincerely, Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
On Mon, 19 Feb 2018 11:29:04 -0600, John McKown wrote:
>On Mon, Feb 19, 2018 at 7:04 AM, Gary Freestone wrote:
>>
>> Chasing down a bug in my code lead me to discover an idiosyncrasy with
>> BPXWDYN that I think is a bug, but maybe not. So I'm seeking your opinions.
>
>I think this is normal for SVC 99 (DYNALLOC).
>
There's a flag in a TU, S99NOCNV, to control it.
>>
>> If I have the following
>>
>> Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"
>> Say 'DDname allocated is 'dd
>> Call bpxwdyn "Free fi("dd")"
>>
>Hum, what I would try is to add the "CLOSE" parameter in the BPXWDYN
>parameter list. The "CLOSE" parameter is not accepted on z/OS 1.12, but is
>on z/OS 2.3. And, on z/OS 2.3, this results in the second BPXWDYN getting a
>different DD name.
>
Feels wrong. I thought Gary wanted to keep the original allocation so there
would be two of them, not free the first.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
On Mon, 19 Feb 2018 18:17:17 +, Frank Swarbrick wrote: >For whatever its worth, once you determine what "ASCII" code page the source >is in and what EBCDIC code page you want the result in you can use Enterprise >COBOL native intrinsic functions to perform the conversion. Let's assume(!) >that the source code page is just the basic Latin-1/ISO-8859-1 (IBM CCSID 819) >and the EBCDIC code page is U.K. Latin-1 (CCSID 285)... > >MOVE FUNCTION DISPLAY-OF ( FUNCTION NATIONAL-OF (ASCII-IN, 819) , 285 ) TO >EBCDIC-OUT > >The "inner function" converts from ASCII CCSID 819 to UTF-16, and the outer >function converts from UTF-16 to EBCDIC CCSID 285. > >This doesn't, of course, answer the question of what the source code page is. >They either need to tell you or it needs to be provided as part of the >protocol. > Nor does it answer the question of how to handle the error that should be reported on encountering a CCSID 819 character not present in 285. If the user is in UK, it's likely to be ISO-8859-15 (CCSID 923) rather than 819. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
On Mon, 19 Feb 2018 12:12:07 -0600, Alan Altmark wrote: > >I've been doing code page and translation table development and analysis since >about 1987. The term "ASCII" is just as ambiguous as "EBCDIC", as without >qualification each term only sets an expectation for the 8-bit encoding of a >somewhat vague set of glyphs. > How about USASCII? Is that unambiguously the 7-bit set? I've encountered two EBCDIC C implementations. One of them returned "true" if the EBCDIC character translated to ASCII was a USASCII character. The other returned :true" simply if the EBCDIC code point was less than 128. >The original 7-bit ASCII established a full 95-glyph character set that >remains invariant today among all 8-bit ASCII code pages. EBCDIC wasn't >quite so lucky, as it has only 56 invariant characters. It would be 82, but >lower case a-z can vary or be non-existent. If your data is composed of only >the 56 common invariant characters, any EBCDIC and ASCII code page will >suffice. All "Latin" EBCDIC code pages will work for lower case a-z. > That's *so* 20th century! And 95 is better than 56. And luck had little to do with it; it was more lackadaisical design. 7-bit ASCII was extant when EBCDIC was conceived. Prudence should have dictated that EBCDIC code points correspinding to those 95 glyphs be kept invariant. If the domain of practically any problem is sufficiently restricted the solution becomes trivial. And mostly useless. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
I can't speak for BPXWDYN, but I remember when REUSE became available in TSO.
Before that, a CLIST writer (this was before REXX was ported to TSO) had to
code like this:
CONTROL NOMSG
FREE DD(like-I-care-if-it's-allocated)
CONTROL MSG
ALLOC DD(now-I-want-it) ...
This was necessary because if the DD was not already allocated, a gratuitous
FREE would give the user a snarky message to that effect. With REUSE, the
allocation would take place with no distraction to the user either way.
The result was the *same* DD allocated to the data set(s) desired. This goes
back to around 1980 +/-.
.
.
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 Paul Gilmartin
Sent: Monday, February 19, 2018 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: BPXWDYN - Bug or no bug ?
On Mon, 19 Feb 2018 11:29:04 -0600, John McKown wrote:
>On Mon, Feb 19, 2018 at 7:04 AM, Gary Freestone wrote:
>>
>> Chasing down a bug in my code lead me to discover an idiosyncrasy
>> with BPXWDYN that I think is a bug, but maybe not. So I'm seeking your
>> opinions.
>
>I think this is normal for SVC 99 (DYNALLOC).
>
There's a flag in a TU, S99NOCNV, to control it.
>>
>> If I have the following
>>
>> Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"
>> Say 'DDname allocated is 'dd
>> Call bpxwdyn "Free fi("dd")"
>>
>Hum, what I would try is to add the "CLOSE" parameter in the BPXWDYN
>parameter list. The "CLOSE" parameter is not accepted on z/OS 1.12,
>but is on z/OS 2.3. And, on z/OS 2.3, this results in the second
>BPXWDYN getting a different DD name.
>
Feels wrong. I thought Gary wanted to keep the original allocation so there
would be two of them, not free the first.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
On Mon, 19 Feb 2018 20:14:29 +, Jesse 1 Robinson wrote: >I can't speak for BPXWDYN, but I remember when REUSE became available in TSO. >Before that, a CLIST writer (this was before REXX was ported to TSO) had to >code like this: > >CONTROL NOMSG >FREE DD(like-I-care-if-it's-allocated) >CONTROL MSG >ALLOC DD(now-I-want-it) ... > >This was necessary because if the DD was not already allocated, a gratuitous >FREE would give the user a snarky message to that effect. > I recall an era when FREE of an unallocated DDNAME was fatal to the CLIST (of course, the programmer should know better!) but ALLOCATE of a DDNAME in use merely gave a snarky message. So, I resorted to: ALLOCATE (like-I-care) FREE ALLOCATE (now-I-want-it). RTDDN was a boon. I still shudder when I see programmers using RANDOM() to generate DDNAMEs and hoping for the best. >With REUSE, the allocation would take place with no distraction to the user >either way. > For many years, REUSE did not work for UNIX files (it's better now). I think there was some semantic confusion about the overloading of "REUSE" and UNIX allocations could never be reused (like-I-care). For some of the interim, BPXWDYN development generously added an internal FREE when the programmer coded REUSE. >The result was the *same* DD allocated to the data set(s) desired. This goes >back to around 1980 +/-. > But I believe that the OP wanted the *same* data set allocated to two different DDNAMES, or at least not to disrupt the existing allocation, and allocation conversion or the REUSE option thwarts that. I don't know the meaning or the intent of allocation conversion, except that it's a PITA. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Programmatically access the SYSTRACE data in a SVCDUMP?
Is there a standard way that an IPCS EXEC (or program, if necessary) can programmatically access the SYSTRACE buffers? Or is the only standard option sending SYSTRACE top a dataset and then scraping it? I would like to pick out certain records and issue a WHERE on the address and then produce a report. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS dataset oddity with COM-Plete
As it is a S0C1, I would look to a branch to low core and if so, look at the calling module for some link error. On Sat, 17 Feb 2018 20:21:59 -0600 Brian Westerman wrote: :>No, the volumes are identical (same raid, same channels, etc.) except that the one (that results in an s0C1) is in an SMS pool and the other is not. The data got to the pool because we sent it there via a dfdss batch job to move all of the development datasets to a "new" 48 volume development pool instead of just a few development 3390-3's. :>The only difference between them via 3.4 seems to be that one has a storage class and management class (no dataclass) and the other doesn't (because it's not on an SMS volume. :>The vendor (SAG) is no help at all, as they feel that since Com-Plete 6.8.1 works fine with it on either volume that we should just migrate to the new version now. Unfortunately, that's not a viable option because they have to upgrade Natural and Adabas first and that project has just started (that's why the Com-Plete cutover is January of 2019). :>Strangely enough, we have another customer, at the same level of Com-Plete, exactly same PTF level and compile dates on the programs, and they have no problem editing dataset from the SMS volumes. :>I have compared the sites com-plete (s) and they are not just virtually identical, they are exactly identical. :>One site though (the site that works) is z/OS 1.8 (in the process of moving to z/OS 2.3), but the other (the one where it fails) is at z/OS 2.2. :>I have no real doubts that the issue is something within SMS under z/OS 2.2 (or something that changed between 1.8 and 2.2), but the problem is to locate and neutralize it before the site that is currently converting to 2.3 ends up with the same issue. They have no plans to upgrade their Software AG environment (it's slowly disappearing). -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN - Bug or no bug ?
Gary,
Use this trick to let BPXWDYN allocate to a new DD instead of using the
existing one. (Credit to Paul Gilmartin who's made this discovery in one of
his earlier discussion on IBM-Main which is available at
https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/QKKcj6LYBik/tF68-svA50sJ
)
so you just need to supply the RECFM parm to get a new allocation. I chose
RECFM (F,B) . if you're going to actually use the dd, then it is a catch
22 as you need to know ahead of time what the recfm is, However if you do
know the RECFM then here is a work around
Address tso "alloc fi(abug) da('any.dataset.name') shr resue"
Call bpxwdyn,
"Alloc rtddn(dd) da('any.dataset.name') recfm(f,b) shr reuse"
Say 'DDname allocated is 'dd
Call bpxwdyn "Free fi("dd")"
Thanks,
Kolusu
IBM Mainframe Discussion List wrote on
02/19/2018 06:18:13 AM:
> From: Gary Freestone
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 02/19/2018 06:29 AM
> Subject: BPXWDYN - Bug or no bug ?
> Sent by: IBM Mainframe Discussion List
>
> These days we are opting for BPXWDYN in our REXXs instead of TSO ALLOC.
One
> of the main reason for the switch is BPXWDYN's ability to return the
DDNAME
> it allocated via the RTDDN parameter.
>
>
>
> Chasing down a bug in my code lead me to discover an idiosyncrasy with
> BPXWDYN that I think is a bug, but maybe not. So I'm seeking your
opinions.
>
>
>
> If I have the following
>
>
>
>
>
> Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"
>
> Say 'DDname allocated is 'dd
>
> Call bpxwdyn "Free fi("dd")"
>
> Running this exec gives something like "DDname allocated is SYS00746"
>
> However, if any.dataset.name is already allocated to an alternate DDNAME
> that is not in concatenation then, instead of allocating a new DDname it
> just returns the DDNAME of the existing allocation.
>
> You can see this with this code
>
> Address tso "alloc fi(abug) da('any.dataset.name') shr resue"
>
> Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"
>
> Say 'DDname allocated is 'dd
>
> Call bpxwdyn "Free fi("dd")"
>
> And you will get "DDname allocated is ABUG"
>
> Problem is because I'm not getting a new allocation my FREE is freeing up
a
> DDNAME allocated by a totally different process. In my case causing an
> abend sometime later because a DDname that should be allocated is not.
>
> This doesn't seem right to me. An "ALLOC" should do a new allocation
every
> time.
>
>
>
> Comments
>
>
>
>
>
> Gary Freestone
>
>
>
>
> --
> 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: Programmatically access the SYSTRACE data in a SVCDUMP?
On 2018-02-19 16:07, Binyamin Dissen wrote: Is there a standard way that an IPCS EXEC (or program, if necessary) can programmatically access the SYSTRACE buffers? Or is the only standard option sending SYSTRACE top a dataset and then scraping it? I would like to pick out certain records and issue a WHERE on the address and then produce a report. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN What I've done is: 1. Send SYSTRACE output to a data set. 2. Use an edit macro that generates a REXX exec that contains IPCS NOTE commands to show the trace lines and IPCS WHERE commands for the PSW addresses in the trace lines. 3. Run the generated exec in IPCS. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
Can you find out the IP address the file is coming from? If so, then you could look up the country by looking in the assigned range table. https://www.codeproject.com/Articles/28363/How-to-convert-IP-address-to-country-name On Mon, Feb 19, 2018 at 8:08 AM, scott Ford wrote: > Phil/Gil: > > Correct, sorry been a week, CP285 is a UK EBCDIC codepage. > But my question still stands ... > > 1. PC/Linux -> sends ascii encrypted data to IBM z/OS , like I mentioned a > STC in Cobol > 2. The STC decrypts and then converts to EBCDIC... > > My issue is CAN i query a codepage or CCSID on z/OS to find out what the > customer is using without a parameter of some sort. > > Regards, > > On Sun, Feb 18, 2018 at 8:34 PM, Mike Schwab > wrote: > >> Knowing what country the data is coming from would greatly reduce the >> possibilities to one or a handful of code pages. >> >> On Sun, Feb 18, 2018 at 3:40 PM, Phil Smith III wrote: >> > scott Ford wrote, in part: >> > >> >>The ASCII is CP 285 UK ..but we have to support all .I am making sure I >> > >> > >> > >> > That's not ASCII. This is the point others have been making: you can't >> > really say "ASCII" unless you mean x'00' through x'127' *and nothing >> else*: >> > all you can say is "It's not EBCDIC". Once you start talking other "code >> > pages", you either need to know which it is, or you have to make an >> > assumption. Period. >> > >> > >> > >> > And from my reading, code page 285 is an EBCDIC code page. >> > >> > >> > >> > Sorry to sound like a hardass about this, but I'm not sure your question >> has >> > a meaningful answer, based on what you've said so far. >> > >> > >> > >> > .phsiii >> > >> > >> > -- >> > 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 >> > > > > -- > > > > *IDMWORKS * > > Scott Ford > > z/OS Dev. > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning a > friend or collegue you demean yourself” > > > > www.idmworks.com > > scott.f...@idmworks.com > > Blog: www.idmworks.com/blog > > > > > > *The information contained in this email message and any attachment may be > privileged, confidential, proprietary or otherwise protected from > disclosure. If the reader of this message is not the intended recipient, > you are hereby notified that any dissemination, distribution, copying or > use of this message and any attachment is strictly prohibited. If you have > received this message in error, please notify us immediately by replying to > the message and permanently delete it from your computer and destroy any > printout thereof.* > > -- > 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
Re: BPXWDYN - Bug or no bug ?
On Mon, 19 Feb 2018 08:46:50 -0500, Steve Smith wrote: >You need to set flag "S99NOCNV Do not use an existing allocation to satisfy >this request." But I don't know if BPXWDYN allows this. > z/OSIBM Using REXX and z/OS UNIX System Services Version 2 Release 3 SA23-2283-30 Chapter 6. BPXWDYN: a text interface to dynamic allocation and dynamic output Requesting dynamic allocation TU(hex-tu-value) Builds an allocation text unit (TU) from the specified string. For example, alloc tu(000100010002c1c2) is equivalent to alloc fi(ab). TU can be used multiple times in an allocation request. Ugh. >Depends on what you call a bug... DYNALLOC itself has driven me crazy with >all the various flags and options trying to figure out "convertible", etc. > It's worse than a bug; it's bad design defaulting to obfuscation with the goal of performance. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
LPSERVE not starting
We were testing some new shut-down procedures on our sandbox lPAR and somehow we have messed up LPSERVE. When it starts, it gets the following error: EZY1980E MVPMAIN terminating due to previous error(s). The last time it started correctly, the output had the following : EZB0831I IBM MVS LPD Version CS V2R10 on 02/16/18 at 08:13:47 EZB0832I EZB0705I 02/16/18 08:13:47 EZB0834I Ready EZB0622E Could not get notice (TCP/IP service is being shut down (8558) I have IPLed multiple times and can't seem to get rid of the problem. Any thoughts? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
On Mon, 19 Feb 2018 15:41:11 -0600, Mike Schwab wrote: >Can you find out the IP address the file is coming from? If so, then >you could look up the country by looking in the assigned range table. >https://www.codeproject.com/Articles/28363/How-to-convert-IP-address-to-country-name > Seriously? How many code pages are in use in the USA? And then there's VPN. And multinational organizations. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
If it is coming from a company, they would most likely be in the primary language of the country (or region). If it is coming from an individual, then it could be anything in any country. Could you convince your clients to use UTF-8? On Mon, Feb 19, 2018 at 4:06 PM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 19 Feb 2018 15:41:11 -0600, Mike Schwab wrote: > >>Can you find out the IP address the file is coming from? If so, then >>you could look up the country by looking in the assigned range table. >>https://www.codeproject.com/Articles/28363/How-to-convert-IP-address-to-country-name >> > Seriously? How many code pages are in use in the USA? And then > there's VPN. And multinational organizations. > > -- gil > > -- > 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
Re: SMS dataset oddity with COM-Plete
Binyamin, Does the Management class have space release YI? Decades ago I had a problem with SAS (V6 I think) doing an Open/Close/Open on its datasets that would trigger space release, and then the EXCP would point to a location beyond the EOF. This did not result in an SOC1, but rather a x37 and pinned data in the storage. Altering the space release in the Management class fixed the problem. Just an "out there" suggestion for you to look at. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Monday, February 19, 2018 1:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SMS dataset oddity with COM-Plete As it is a S0C1, I would look to a branch to low core and if so, look at the calling module for some link error. On Sat, 17 Feb 2018 20:21:59 -0600 Brian Westerman wrote: :>No, the volumes are identical (same raid, same channels, etc.) except that the one (that results in an s0C1) is in an SMS pool and the other is not. The data got to the pool because we sent it there via a dfdss batch job to move all of the development datasets to a "new" 48 volume development pool instead of just a few development 3390-3's. :>The only difference between them via 3.4 seems to be that one has a storage class and management class (no dataclass) and the other doesn't (because it's not on an SMS volume. :>The vendor (SAG) is no help at all, as they feel that since Com-Plete 6.8.1 works fine with it on either volume that we should just migrate to the new version now. Unfortunately, that's not a viable option because they have to upgrade Natural and Adabas first and that project has just started (that's why the Com-Plete cutover is January of 2019). :>Strangely enough, we have another customer, at the same level of Com-Plete, exactly same PTF level and compile dates on the programs, and they have no problem editing dataset from the SMS volumes. :>I have compared the sites com-plete (s) and they are not just virtually identical, they are exactly identical. :>One site though (the site that works) is z/OS 1.8 (in the process of moving to z/OS 2.3), but the other (the one where it fails) is at z/OS 2.2. :>I have no real doubts that the issue is something within SMS under z/OS 2.2 (or something that changed between 1.8 and 2.2), but the problem is to locate and neutralize it before the site that is currently converting to 2.3 ends up with the same issue. They have no plans to upgrade their Software AG environment (it's slowly disappearing). -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: HMC log question
On Mon, 19 Feb 2018 15:21:32 +, Vernooij, Kees (ITOPT1) - KLM wrote: >Hello Group, > >It seems a simple question, but we can't find it: >Does the z13s HMC log when a disabled waitstate is loaded and how can I access >the log? > >Or is the only way to find out about these event to email them via the Monitor >System Events function? > >Kees. > Kees, The hardware messages icon should be blue (indicating a h/w message). You should then single click on the CPC (again it should be coloured blue) and then hardware messages and whatever h/w message should then displayed in a popup window. You can also setup, via the Monitor System Events task in the Console Actions Work Area and setup an alert(s) to send an email - this is what we do and it works quite well . Hope this helps . Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
GIM37150S ** THE KEYWORD IS MISSING OR INVALID.
Hi Guys, today got this failure pulling maintenance from IBM. Cannot find any reference to keyword. Anyone can assist? Thanks Bruce Hewson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM37150S ** THE KEYWORD IS MISSING OR INVALID.
No real help, but I saw this post from Tom today... On 2/19/2018 12:40 PM, Pinnacle wrote: > All of our RECEIVE ORDERs are getting GIM37150S THE KEYWORD IS MISSING OR INVALID. I've opened a Sev 1 PMR with IBM. Anybody else seen this and know how to fix it? > > Regards, > Tom Conley > Just got word back from IBM. There's a problem with database replication that the server owners are working on foot>. Regards, Tom Conley Bruce Hewson wrote: Hi Guys, today got this failure pulling maintenance from IBM. Cannot find any reference to keyword. Anyone can assist? Thanks Bruce Hewson -- 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: SMS dataset oddity with COM-Plete
Not active on either site. Brian On Mon, 19 Feb 2018 07:40:25 +, Savor, Thomas (Alpharetta) wrote: >Hardware Compression ?? > >Thanks, > >Tom Savor > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Brian Westerman >Sent: Monday, February 19, 2018 2:02 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMS dataset oddity with COM-Plete > >Changing SWA and keeping the UCB below the line had not effect, the problem >still exists. > >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: SMS dataset oddity with COM-Plete
Yes, It appears to be trying to get the SYSDSN, it has the volser and the dsn in the buffer, but the entire area is in 31bit storage. I don't know why in this case. I don't know why the data would be 31-bit for the same dataset on a SMS volume that is is (apparently) 24bit when it's not on an SMS volume. Brian Brian. On Mon, 19 Feb 2018 13:45:15 +, Pew, Curtis G wrote: >On Feb 19, 2018, at 1:01 AM, Brian Westerman >wrote: >> >> Changing SWA and keeping the UCB below the line had not effect, the problem >> still exists. > >Have you examined *UDUMP to try to firure out what it’s trying to do when the >ABEND occurs? > >- >Pew, Curtis G >curtis@austin.utexas.edu >ITS Systems/Core/Administrative Services > > >-- >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: SMS dataset oddity with COM-Plete
It's a Software AG program, so IBM will just laugh at me. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS dataset oddity with COM-Plete
I had conditional space release, but I just changed it to "N" and activated it, and it didn't help anything. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMC log question
Sometimes they show up in the Machine area (not the LPAR specific area). When the wait is due to hardware I think some HMC's send it there instead of the LPAR specific hardware messages. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMC log question
Did AutoIPL initiate a standalone dump or a reIPL of MVS? Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Discussion List wrote on 02/19/2018 10:44:14 AM: > From: "Vernooij, Kees (ITOPT1) - KLM" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/20/2018 01:35 AM > Subject: Re: HMC log question > Sent by: IBM Mainframe Discussion List > > We thought so too, but the lists are all empty. > > Kees. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Allan Staller > > Sent: 19 February, 2018 16:30 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: HMC log question > > > > HARDWARE messages should have that info. Might be LPAR specific. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Vernooij, Kees (ITOPT1) - KLM > > Sent: Monday, February 19, 2018 9:22 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: HMC log question > > > > Hello Group, > > > > It seems a simple question, but we can't find it: > > Does the z13s HMC log when a disabled waitstate is loaded and how can I > > access the log? > > > > Or is the only way to find out about these event to email them via the > > Monitor System Events function? > > > > Kees. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Programmatically access the SYSTRACE data in a SVCDUMP?
It would be useful be able to specify something like EXIT(program) on the SYSTRACE command, and have it pass you each unformatted trace record that it is going to format. Unfortunately that function does not currently exist. So scraping the formatted SYSTRACE output is the only way to do it, other than knowing how to find and merge the unformatted buffers yourself, which is non-trival, and not an interface Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Discussion List wrote on 02/19/2018 04:07:54 PM: > From: Binyamin Dissen > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/20/2018 01:36 AM > Subject: Programmatically access the SYSTRACE data in a SVCDUMP? > Sent by: IBM Mainframe Discussion List > > Is there a standard way that an IPCS EXEC (or program, if necessary) can > programmatically access the SYSTRACE buffers? > > Or is the only standard option sending SYSTRACE top a dataset and then > scraping it? > > I would like to pick out certain records and issue a WHERE on the address and > then produce a report. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
