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

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"

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 /

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

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

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

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

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

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

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

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

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

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?

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

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.

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:

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

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

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

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

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)

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

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

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(!)

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

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

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

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

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

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 /

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

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

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:

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

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

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

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

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.

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

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: 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

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

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,

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

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,