Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
> > ESPIE for unauthorized programs (like LE) supports interrupt codes > > 1-15 (decimal), which does not include 17 (x'11') page fault. So > > SLIP SET,A=SVCD,C=0C4,RE=11,ML=1,MODE=PP,J=jobname,END > > should be able take a dump of this problem without interference from > > LE's ESPIE. > Admittedly we never specified RE=11 (or mode=pp) on the slip trap we > had attempted for an 0C4 in my last job, but the slip trap on OC4 > only prodcued a dump when TRAP was set to OFF. Maybe what interfered > was the fact that parts of the code were authorized. Maybe Peter's > "middleware infrastructure" is also authorized, at least in parts. You are right, I have to eat those words. ESPIE processing translates unresolved program interrupt codes x'10', x'11', x'38', x'39', x'3A', and x'3B' into program interrupt code 4, so an ESPIE established for interrupt code 4 will also get control for any of those access exceptions when they cannot be resolved. Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting FRR
Can I delete from another work unit e.g TASK before the SRB Returns to dispatcher > On Jul 28, 2016, at 8:29 PM, Greg Dyck wrote: > >> On 7/28/2016 1:00 PM, Joe Reichman wrote: >> I have a FRR covering a SRB it not a parameter on the SCHEDULE or IEAMSCHD >> but rather invoked inside the SRB. The documentation says to delete it just >> code SETFRR D,WORKREGS However I am guessing it has to be in the context of >> the SRB or in the FRR on the SETRP REMREC=YES >> >> But that's only in the retry routine ? > > If you don't enter recovery then explicitly delete the FRR prior to returning > to the dispatcher. > > If you do enter recovery and percolate the error then RTM will implicitly > delete the FRR for you. > > If you do enter recovery and retry, it depends. If you retry to a point > where the FRR does not get explicitly deleted then you should use SETRP > REMREC=YES. If you retry to a point where the FRR does get explicitly > deleted then do nothing in recovery. > > Greg > > -- > 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: Deleting FRR
On 7/28/2016 1:00 PM, Joe Reichman wrote: I have a FRR covering a SRB it not a parameter on the SCHEDULE or IEAMSCHD but rather invoked inside the SRB. The documentation says to delete it just code SETFRR D,WORKREGS However I am guessing it has to be in the context of the SRB or in the FRR on the SETRP REMREC=YES But that's only in the retry routine ? If you don't enter recovery then explicitly delete the FRR prior to returning to the dispatcher. If you do enter recovery and percolate the error then RTM will implicitly delete the FRR for you. If you do enter recovery and retry, it depends. If you retry to a point where the FRR does not get explicitly deleted then you should use SETRP REMREC=YES. If you retry to a point where the FRR does get explicitly deleted then do nothing in recovery. Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMP/E query resolver?
I have in a CSI: Entry Type: SYSMOD Zone Name: GLOBAL Entry Name: HHH Zone Type: GLOBAL HOLD DATA ++ HOLD ( HHH ) ERROR REASON ( RRR ) FMID ( FFF ) DATE (16187) COMMENT ( ... ) . ... ++ HOLD(HHH) SYSTEM REASON(DOC) FMID(FFF) DATE(16074) COMMENT( .. ) . HHH has been APPLYed and ACCEPTed with status APP BYP and ACC BYP. Is there anything in the CSI that will tell me whether RRR was BYPASSed or SUPerseded, and if the latter what the SUPerseding SYSMOD is? I assume the BYP might pertain either to the SYSTEM hold which I know was BYPASSed or to the ERROR hold. (I prefer using the ISPF panels rather than a batch LIST.) Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Initiator - Identify the List of Jobs
Go pull the SMF 30's type 4 and 5 Its all there -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron Hawkins Sent: Thursday, July 28, 2016 4:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Initiator - Identify the List of Jobs Try parsing your syslog -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake Anderson Sent: Wednesday, July 27, 2016 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Initiator - Identify the List of Jobs Initiator 16 alone On Jul 27, 2016 11:13 PM, "Tom Marchant" < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > On Wed, 27 Jul 2016 21:30:33 +0530, Jake Anderson wrote: > > >I am trying to fetch the List of Jobname that used a specific Initiator. > Is > >there a way to determine ? > > Dr. Merrill gave you a clue, but I have a question. > What do you mean by "A specific initiator"? > Do you mean: > 1. For example, initiator 16? > 2. Class B initiator? > 3. A particular iteration of one of the above? That is, an initiator > from the time it was started until it stopped. > 4. Something else? > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Initiator - Identify the List of Jobs
Try parsing your syslog -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake Anderson Sent: Wednesday, July 27, 2016 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Initiator - Identify the List of Jobs Initiator 16 alone On Jul 27, 2016 11:13 PM, "Tom Marchant" < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > On Wed, 27 Jul 2016 21:30:33 +0530, Jake Anderson wrote: > > >I am trying to fetch the List of Jobname that used a specific Initiator. > Is > >there a way to determine ? > > Dr. Merrill gave you a clue, but I have a question. > What do you mean by "A specific initiator"? > Do you mean: > 1. For example, initiator 16? > 2. Class B initiator? > 3. A particular iteration of one of the above? That is, an initiator > from the time it was started until it stopped. > 4. Something else? > > -- > Tom Marchant > > -- > 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: SMP/E packaging question
Sorry, I am doing a terrible job explaining this. The "outside of SMP/E" link job doesn't do the link directly by invoking HEWL, but rather by invoking SMP/E with SET BOUNDARY(TARGET) . LINK LMODS CALLLIBS . So it's "outside of SMP/E" in the sense of being *submitted* outside of the APPLY/ACCEPT process, but it *does* invoke SMP/E. Does that help? Or make it worse? Thanks Rich Way -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, July 28, 2016 1:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E packaging question On Thu, 28 Jul 2016 18:52:40 +, Way, Richard wrote: >Sorry, correction of my clarification (not that anyone probably much >cares that much anymore, but I do want to be accurate) - delete "open source" >from the sentence below and replace with "IBM component". > >Rich Way > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >On Behalf Of Way, Richard >Sent: Thursday, July 28, 2016 11:05 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMP/E packaging question > >Sorry for the lack of response - I was out of the office for a couple of days. >Apparently it's a long story, predating my tenure here, but has to do >with including some open source object code and not being certain about >SMP picking up all of the dependencies should any of those modules change. >"Sub-optimal", I know. Ok, so if I understand correctly, you have an SMP/E packaged product that includes a load module. That load module was created using SMP/E without an alias that it should have. You then link that load module outside of SMP/E to include an IBM component. Here are more questions. Was the load module linked correctly by SMP/E? I assume not because you seem to have identified that the JCLIN was missing the alias. When you link the module after APPLY outside of SMP/E, do you link it back into the SMP/E target library or into another PDS? In any case, the JCLIN that you provide to SMP/E for this LMOD will not cause the second link outside of SMP/E to have the alias. -- Tom Marchant -- 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: SMP/E packaging question
On Thu, 28 Jul 2016 18:52:40 +, Way, Richard wrote: >Sorry, correction of my clarification (not that anyone probably much cares >that much anymore, but I do want to be accurate) - delete "open source" >from the sentence below and replace with "IBM component". > >Rich Way > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Way, Richard >Sent: Thursday, July 28, 2016 11:05 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMP/E packaging question > >Sorry for the lack of response - I was out of the office for a couple of days. >Apparently it's a long story, predating my tenure here, but has to do with >including some open source object code and not being certain about SMP >picking up all of the dependencies should any of those modules change. >"Sub-optimal", I know. Ok, so if I understand correctly, you have an SMP/E packaged product that includes a load module. That load module was created using SMP/E without an alias that it should have. You then link that load module outside of SMP/E to include an IBM component. Here are more questions. Was the load module linked correctly by SMP/E? I assume not because you seem to have identified that the JCLIN was missing the alias. When you link the module after APPLY outside of SMP/E, do you link it back into the SMP/E target library or into another PDS? In any case, the JCLIN that you provide to SMP/E for this LMOD will not cause the second link outside of SMP/E to have the alias. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Deleting FRR
Hi, I have a FRR covering a SRB it not a parameter on the SCHEDULE or IEAMSCHD but rather invoked inside the SRB. The documentation says to delete it just code SETFRR D,WORKREGS However I am guessing it has to be in the context of the SRB or in the FRR on the SETRP REMREC=YES But that's only in the retry routine ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E packaging question
Sorry, correction of my clarification (not that anyone probably much cares that much anymore, but I do want to be accurate) - delete "open source" from the sentence below and replace with "IBM component". Rich Way -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Way, Richard Sent: Thursday, July 28, 2016 11:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E packaging question Sorry for the lack of response - I was out of the office for a couple of days. Apparently it's a long story, predating my tenure here, but has to do with including some open source object code and not being certain about SMP picking up all of the dependencies should any of those modules change. "Sub-optimal", I know. Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Monday, July 25, 2016 12:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E packaging question On Mon, 25 Jul 2016 13:51:28 -0500, Tom Marchant wrote: >On Mon, 25 Jul 2016 18:36:13 +, Way, Richard wrote: > >>I should have mentioned that we have customers run a separate link job anyway >>after the RECEIVE/APPLY/ACCEPT. > >Why? What I mean is, do you run an SMP/E LINK LMODS or LINK MODULE command? Or do you link edit the modules outside of SMP/E? And in either case, why do you do that? -- Tom Marchant -- 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: SMP/E packaging question
Thanks!! Will definitely look at that example - it's virtually identical to my use case. Rich Way -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Fleury Sent: Tuesday, July 26, 2016 8:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E packaging question Subject: SMP/E packaging question From: "Way, Richard" Reply-To: IBM Mainframe Discussion List eply I need to provide SMP service to an existing released product to fix the binder control cards (only) due to some missing load module ALIASes. Can someone assist with identifying the steps we'd follow to accomplish this, please? I know what changes I want to make to the binder control cards, but I am not versed in SMP/E (obviously). I believe we'd just need to update the JCLIN and get them to RECEIVE/APPLY/ACCEPT the resultant PTF, but I am unclear on the details. Thanks! Rich Way HPE Security - Data Security You might want to look at a sample usermod that comes with High Level Assembler to add an alias IEV90 to ASMA90. It is documented in the Inastallation and Customization Guide chapter 4 (SC26-3494), and is distributed as member ASMAIEV in ASM.SASMSAM1. The trick is to include a ++MOD for a module from the target library (LKLIB). When I last installed this on z/OS 2.1 the binder output report showed an include for SASMMOD1(ASMA90), effectively replacing the load module with itself. Hope this helps! -- 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: SMP/E packaging question
Sorry for the lack of response - I was out of the office for a couple of days. Apparently it's a long story, predating my tenure here, but has to do with including some open source object code and not being certain about SMP picking up all of the dependencies should any of those modules change. "Sub-optimal", I know. Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Monday, July 25, 2016 12:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E packaging question On Mon, 25 Jul 2016 13:51:28 -0500, Tom Marchant wrote: >On Mon, 25 Jul 2016 18:36:13 +, Way, Richard wrote: > >>I should have mentioned that we have customers run a separate link job anyway >>after the RECEIVE/APPLY/ACCEPT. > >Why? What I mean is, do you run an SMP/E LINK LMODS or LINK MODULE command? Or do you link edit the modules outside of SMP/E? And in either case, why do you do that? -- Tom Marchant -- 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
HTTP Enabler get http 400 error
Co-posted to IBM-Main & IBM TCP/IP. Anyone experienced with HTTP Enabler? The server is Apache running on CENTOS configured with AddDefaultCharset IOS-8859-1. No data is sent in the POST method, but anyway, I force RESPBody & BODY A2E and viceversa translations. in response to HWTHRQST I get http400 and a long xml (not translated for some reasons...) saying "server does not understand...". Any idea? Best, ITschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: AW: Re: codepage restrictions on IBM applications
On Thu, 28 Jul 2016 10:23:05 +0200, Peter Hunkeler wrote:
>...
>I'm not sure whether the text is inspected by WTO or only later by CONSOLE
>when displaying on consoles. The later would make sense to me. You want to
>avoid that strange things happen when strange data is displayed on terminals
>(consoles). Syslog is actually nothing but a data set consting of records.
>Should be able to cope with any byte content.
>
Decades ago, when I was new to TSO (and Rexx wasn't available), I noted
empirically
that TSO was insensitive to case for commands entered at the READY prompt. I
tried using this concept writing a CLIST. Overgeneralized. I got:
IKJE UNKNOWN COMMAND 'DO'.
Well, I had typed "do". The TMP tried to parse it asis, failed, then
translated it
to majuscule to issue the message, thereby obfuscating the nature of the error.
Somewhat similarly, if I enter on most ISPF command lines:
TSO ALLOCATE PATH('/dev/null')
I get:
IKJI PATH ('/DEV/NULL') NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED.
Slightly different in that the harmful translation is performed *before*
attempting
to elaborate the command. ISPF should *never* convert the case of the TSO
command; just pass it to the TMP as typed.
>Tools such as SDSF which display the syslog would then again make sure only
>harmless characters are displayed..
>
ISPF is well aware of terminal code pages and filters nondisplable characters.
ISPF support was glad to fix by APAR an error I discovered in this processing.
Don't know about SDSF from the TSO READY prompt.
>Opinions? I'm thinking about sending an RCF asking for clear description of
>this.
>
Ouch! You'll be in a thicket of code pages and CCSIDs. They *might* provide
CP037-based list of characters and hex code points. How useful would that
information be? I doubt they'll respect case in operator commands even where
it matters, such as UNIX mountpoints.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RFE: Add support to EDCDSECT for generating Doxygen-compatible comments
All, I've submitted a new RFE for z/OS XL C/C++, requesting that its comment generation be enhanced so that it can generate comments that are recognized by Doxygen. This should be helpful for anyone that shares data areas between Assembler and C/C++ code. Here's a link to the RFE: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=92319 If you like it, please vote for it! Thanks! -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CERTAUTH vs SITE vs user certificate
Not true, we have tried it. You need to use the RDATALIB with a site certificate. Try it. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm Sent: Wednesday, July 27, 2016 11:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CERTAUTH vs SITE vs user certificate Actually with RDATALIB, you should be able to share a cert with multiple regions as well without using SITE. Rob Schramm On Wed, Jul 27, 2016, 12:01 PM Ward, Mike S wrote: > I know that a site certificate can b e shared by many CICS regions > with different controlling userids. A user certificate requires that > each region that is sharing the cert have the same userid. Hope that helps. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Phil Smith III > Sent: Thursday, July 14, 2016 1:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: CERTAUTH vs SITE vs user certificate > > I've never understood how you choose between adding a certificate as > CERTAUTH, SITE, or user. And not having a lot of luck Googling for it. > Can anyone describe the choice, or point me at something coherent? > > > > Thanks. > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > == > This email, and any files transmitted with it, is confidential and > intended solely for the use of the individual or entity to which it is > addressed. If you have received this email in error, please notify the > system manager. This message contains confidential information and is > intended only for the individual named. If you are not the named > addressee, you should not disseminate, distribute or copy this e-mail. > Please notify the sender immediately by e-mail if you have received > this message by mistake and delete this e-mail from your system. If > you are not the intended recipient, you are notified that disclosing, > copying, distributing or taking any action in reliance on the contents > of this information is strictly prohibited. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: fopen() errno=41 errno2=0xc00a0022 last_op=111 errorCode=0xfe0000
Right. The JZOS ZFile(path, options) maps to fopen(path, options), so
there should be no difference. ZFile is a thin wrapper around the C
library I/O routines.
Assuming that IBM says that VRRDS is not supported, I would encourage you
to write an RFE for VRRDS support in the C library.
https://www.ibm.com/developerworks/rfe/
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Thu, Jul 28, 2016 at 8:57 AM, Steve Austin
wrote:
> Thanks for this Kirk,
>
> I ran up a C program and got the same error for a VRRDS. I guess the VRRDS
> type is not greatly used; by Java and C programmers anyway.
>
> Steve
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Kirk Wolf
> Sent: 28 July 2016 14:48
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: fopen() errno=41 errno2=0xc00a0022 last_op=111
> errorCode=0xfe
>
> The relevant diagnostic documentation for debugging C library I/O routine
> errors is "Language Environment Debugging Guide" and "Debuggin I/O
> programs" in the C/C++ Programming Guide.
>
> From the LE Debugging Guide, under "Using the __amrc and __amrc2
> structures":
>
> It appears that the C library fopen routine failed while issuing a TESTCB
> macro (last_op=111).
> The TESTCB RC/Ftncd/FDBK is FE/00/00, which doesn't make sense to me.
>
> My assumption is that you are correct and fopen() doesn't support VRRDS,
> since there is no documented support in the manuals that I can see.
>
> Best to open an ETR with IBM z/OS Language Environment
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> On Thu, Jul 28, 2016 at 5:09 AM, Steve Austin
> wrote:
>
> > EDC5041I An error was detected at the system level when opening a
> > file.;
> > errno=41 errno2=0xc00a0022 last_op=111 errorCode=0xfe
> >
> > I get the above error when using JZOS to open a VSAM VRRDS dataset;
> > the same code works for KSDS and RRDS files.
> >
> > String options = "rb+,type=record";
> > ZFile zfile = new ZFile("//'" + fileName + "'", options);
> >
> > I believe the error is from the C/C++ library fopen() routine, but the
> > errno2 value is undocumented;
> > http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos
> > .v2r1.ceea900/llerr2.htm
> >
> > Does fopen() support VSAM VRRDS files? Any idea what the errno2 value
> > means?
> >
> > Thanks
> >
> > Steve
> >
> > --
> > This e-mail message has been scanned and cleared by Google Message
> > Security and the UNICOM Global security systems. This message is for
> > the named person's use only. If you receive this message in error,
> > please delete it and notify the sender.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> This e-mail message has been scanned and cleared by Google Message Security
> and the UNICOM Global security systems. This message is for the named
> person's use only. If you receive this message in error, please delete it
> and notify the sender.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: fopen() errno=41 errno2=0xc00a0022 last_op=111 errorCode=0xfe0000
Thanks for this Kirk,
I ran up a C program and got the same error for a VRRDS. I guess the VRRDS type
is not greatly used; by Java and C programmers anyway.
Steve
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Kirk Wolf
Sent: 28 July 2016 14:48
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: fopen() errno=41 errno2=0xc00a0022 last_op=111 errorCode=0xfe
The relevant diagnostic documentation for debugging C library I/O routine
errors is "Language Environment Debugging Guide" and "Debuggin I/O programs" in
the C/C++ Programming Guide.
>From the LE Debugging Guide, under "Using the __amrc and __amrc2
structures":
It appears that the C library fopen routine failed while issuing a TESTCB macro
(last_op=111).
The TESTCB RC/Ftncd/FDBK is FE/00/00, which doesn't make sense to me.
My assumption is that you are correct and fopen() doesn't support VRRDS, since
there is no documented support in the manuals that I can see.
Best to open an ETR with IBM z/OS Language Environment
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Thu, Jul 28, 2016 at 5:09 AM, Steve Austin
wrote:
> EDC5041I An error was detected at the system level when opening a
> file.;
> errno=41 errno2=0xc00a0022 last_op=111 errorCode=0xfe
>
> I get the above error when using JZOS to open a VSAM VRRDS dataset;
> the same code works for KSDS and RRDS files.
>
> String options = "rb+,type=record";
> ZFile zfile = new ZFile("//'" + fileName + "'", options);
>
> I believe the error is from the C/C++ library fopen() routine, but the
> errno2 value is undocumented;
> http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos
> .v2r1.ceea900/llerr2.htm
>
> Does fopen() support VSAM VRRDS files? Any idea what the errno2 value
> means?
>
> Thanks
>
> Steve
>
> --
> This e-mail message has been scanned and cleared by Google Message
> Security and the UNICOM Global security systems. This message is for
> the named person's use only. If you receive this message in error,
> please delete it and notify the sender.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
This e-mail message has been scanned and cleared by Google Message Security
and the UNICOM Global security systems. This message is for the named
person's use only. If you receive this message in error, please delete it
and notify the sender.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: fopen() errno=41 errno2=0xc00a0022 last_op=111 errorCode=0xfe0000
The relevant diagnostic documentation for debugging C library I/O routine
errors is "Language Environment Debugging Guide" and "Debuggin I/O
programs" in the C/C++ Programming Guide.
>From the LE Debugging Guide, under "Using the __amrc and __amrc2
structures":
It appears that the C library fopen routine failed while issuing a TESTCB
macro (last_op=111).
The TESTCB RC/Ftncd/FDBK is FE/00/00, which doesn't make sense to me.
My assumption is that you are correct and fopen() doesn't support VRRDS,
since there is no documented support in the manuals that I can see.
Best to open an ETR with IBM z/OS Language Environment
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Thu, Jul 28, 2016 at 5:09 AM, Steve Austin
wrote:
> EDC5041I An error was detected at the system level when opening a file.;
> errno=41 errno2=0xc00a0022 last_op=111 errorCode=0xfe
>
> I get the above error when using JZOS to open a VSAM VRRDS dataset; the
> same code works for KSDS and RRDS files.
>
> String options = "rb+,type=record";
> ZFile zfile = new ZFile("//'" + fileName + "'", options);
>
> I believe the error is from the C/C++ library fopen() routine, but the
> errno2 value is undocumented;
> http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea900/llerr2.htm
>
> Does fopen() support VSAM VRRDS files? Any idea what the errno2 value
> means?
>
> Thanks
>
> Steve
>
> --
> This e-mail message has been scanned and cleared by Google Message Security
> and the UNICOM Global security systems. This message is for the named
> person's use only. If you receive this message in error, please delete it
> and notify the sender.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Softcopy Librarian & Knowledge Center Content
Ron, You have two options depending on where you want to use the assets: 1) Use Knowledge Center for Z (KC4Z) that gets shipped with zOS. Obviously, this is going to come up on your intranet from a zOS session. You can use Softcopy Librarian (SCL) to upload the KC plug-ins OR 2) Download the Knowledge Center Customer Installed (KCCI) which should run on Windows. FWIW: Besides the elements and features, CICS Transaction Services has plug-ins. For base/features, we are trying to keep to a strict quarterly update cadence with real "GAs" coming out in the nearest quarter past the products GA. If you want more content, please respond to RFE 84246. Kevin Minerley k60ek...@us.ibm.com Softcopy Architect for z/OS, z/VM, z/VSE where "softcopy" is BookManager (deprecated), PDFs, and Knowledge Center (KC4Z) plug-ins for base/features -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Softcopy Librarian & Knowledge Center Content
On Thursday, July 28, 2016, Ron MacRae wrote: > Hi all, > As I've just been forced to upgrade my laptop to Windows 10 I had to upgrade Sofcopy Librarian to 5.1. When I went to the list of Internet downloads I saw a few new collections labeled KnowledgeCenter. I set up the new subdirectories in my repository and downloaded a few KC collections. They show up in my Repository as "Knowledge Center Content". > > My question is how do I access this stuff on my PC? > Softcopy Reader doesnt seem to see them, or do I need to change some settings there too? > > Anyone got this working? > > Ron. > I believe the intent of the KC files available via Librarian is to populate a source for Knowledge Center for z/OS, now included with base z/OS 2.2. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Softcopy Librarian & Knowledge Center Content
Hi all, As I've just been forced to upgrade my laptop to Windows 10 I had to upgrade Sofcopy Librarian to 5.1. When I went to the list of Internet downloads I saw a few new collections labeled KnowledgeCenter. I set up the new subdirectories in my repository and downloaded a few KC collections. They show up in my Repository as "Knowledge Center Content". My question is how do I access this stuff on my PC? Softcopy Reader doesnt seem to see them, or do I need to change some settings there too? Anyone got this working? Ron. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
fopen() errno=41 errno2=0xc00a0022 last_op=111 errorCode=0xfe0000
EDC5041I An error was detected at the system level when opening a file.;
errno=41 errno2=0xc00a0022 last_op=111 errorCode=0xfe
I get the above error when using JZOS to open a VSAM VRRDS dataset; the same
code works for KSDS and RRDS files.
String options = "rb+,type=record";
ZFile zfile = new ZFile("//'" + fileName + "'", options);
I believe the error is from the C/C++ library fopen() routine, but the errno2
value is undocumented;
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea900/llerr2.htm
Does fopen() support VSAM VRRDS files? Any idea what the errno2 value means?
Thanks
Steve
--
This e-mail message has been scanned and cleared by Google Message Security
and the UNICOM Global security systems. This message is for the named
person's use only. If you receive this message in error, please delete it
and notify the sender.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
S0C4-11 abend caused by BASSM to address with all X'00' bytes
HRDRFREA has had at least part of its "executable code" overwritten. That has caused a branch, directly or indirectly (through more than one branch), to somewhere close to where it abended. As soon as it branches out of the COBOL program, the information is irrelevant for problem determination without a "full" dump. HRDRFREA looks to be six CALLs deep. ZTVXXX00, HRDEFREA or any of the other modules involved in that specific chain, or any other module that has been CALLed previously in that run-unit, has caused the overwriting. One particular record "causes" the issue. Bear in mind that this may not be so. The issue may be there every day (overwriting) but only some combination of conditions prompted by that record presents the busted code for execution, or in a similar way but only on a few days, or only on that day - those conditions can be from other records, external data relating to those other records (DB or other reference data), previous program state. Or it may directly be that record causing, and suffering from, the overwriting. But that may be directly, or relying on previous state, as above. Without at least a dump containing the executable code of HRDRFREA it is "difficult" to establish what has happened. The investigator (singular - if you have multiple people looking at it, each should work singly) must be aware of the many possibilities, and be open to others. They have to be completely open - preconceptions will lead astray. After working for a period of time, take a break from looking at it. You've probably already missed it. Clear new preconceptions. You start with that record. That record is going to get you there. You have to conceptualise how that record becomes an abend. The "short-cuts" will usually get you there, or on the road. You find a mismatch in parameters, now you have to say "how does that cause the problem"? You may just be noticing another "issue", with no connection to the one at hand. Same with subscripting, reference-modification and the use of pointers. Don't just jump on the first error, fix, recompile and then go with it. Even if the run then completes, it may only be because now something less significant (for that run) has been overwritten, simply through the changed code from the fix (the overwriting only needs to move by one byte to have a different, even benign, result). Until the failure can be fully explained by what is discovered, it cannot be resolved. Suggested explanations should also be tested against "and why doesn't it fail every day" and similar. Yes, it's easier with a full dump, but sometimes you don't have a full dump. If the issue is sufficiently important, then "escalation" may allow some way to get sufficiently more information. "We absolutely need this, and the only way we can get it is by doing that", followed by "signatures of power" may be a possibility. Also, of course, and you probably already are, review the exact use of the tools for cases like this (when the far-from-usual happens). 99% of the time a formatted dump is going to be sufficient. The other 1% consumes 99.999% of abend-solving time (for COBOL application programs). Figures are invented, but intended to be indicative. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: codepage restrictions on IBM applications
I had a look at manual z/OS V2.1 MVS Assembler Services Guide. It describes the characters "... that will be displayed on the console..." in a table. This tbale contains this table shows a lot of special characters as well as all upper *and* lower case letters. It also say that characters not in the table will be replaced by blanks weh displayed on the console. Unfortunately, the manual does not talk about how the message text is treated when written to the syslog. A quick experiment shows that besides above characters, als accented characters show unchanged in syslog. I can't verify what is displayed on the console. I'm not sure whether the text is inspected by WTO or only later by CONSOLE when displaying on consoles. The later would make sense to me. You want to avoid that strange things happen when strange data is displayed on terminals (consoles). Syslog is actually nothing but a data set consting of records. Should be able to cope with any byte content. Tools such as SDSF which display the syslog would then again make sure only harmless characters are displayed.. Opinions? I'm thinking about sending an RCF asking for clear description of this. --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
> All I'm looking for is a system trace. Hoping to find hints what do look for > next. Make sure that you have your systrace set at maximum, then (not the default 64K, and even 1MB will not be enough, especially on a busy system). LE processing takes up a whole lot of real estate in systrace from the inintial incident to the time the trace actually gets captured. > I did in parallel to the discussion here and succeeded. I now know how to > change the options, but as you might have guessed, I'm working for a large > company. And large companies have processes. It will take quite some time to > bring those changed options to production, once I could convince engineering > to actually do it. Do I know about processes! :-( > Not at will, yet, but it reocurred in production. Application people are > still trying to reproduce it in test. Would make everyting much easier. Did you get the same set of insufficient dump data? Just for comparison - were the same addresses involved? > ESPIE for unauthorized programs (like LE) supports interrupt codes > 1-15 (decimal), which does not include 17 (x'11') page fault. So > SLIP SET,A=SVCD,C=0C4,RE=11,ML=1,MODE=PP,J=jobname,END > should be able take a dump of this problem without interference from > LE's ESPIE. Admittedly we never specified RE=11 (or mode=pp) on the slip trap we had attempted for an 0C4 in my last job, but the slip trap on OC4 only prodcued a dump when TRAP was set to OFF. Maybe what interfered was the fact that parts of the code were authorized. Maybe Peter's "middleware infrastructure" is also authorized, at least in parts. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
