AW: Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

> Interesting. A reference to _gtca() also in LE Vendor Interfaces. Hints here > and there in the C/C++ docs. I suspect _gtca() does something similar to what is described in "Chapter 14. Anchor support" in the LE Vendor Interfaces manual. -- Peter Hunkeler

Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

Interesting. A reference to _gtca() also in LE Vendor Interfaces. Hints here and there in the C/C++ docs. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Kielstra Sent: Thursday, May 11, 2017 4:37 PM To:

Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

Bernd's assembler technique will work. I have no idea why I can't find a description of this (taken from /usr/include/stdio.h) #ifndef __gtca #define __gtca() _gtca() #ifdef __cplusplus extern "builtin" #else #pragma linkage(_gtca,builtin) #endif const void

Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

> I know of people using SR RF,RF - but I never saw SLR RF,RF up until now This issue has been beat to death here but on recent processors SR, SLR and XR to clear a register are all equally fast. Use whichever one you find most aesthetic. At one time LHI r,0 was generally faster because

Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

Am 12.05.2017 um 00:08 schrieb John McKown: On Thu, May 11, 2017 at 4:55 PM, Bernd Oppolzer wrote: Yes, of course. I detected the error when I looked at my piece of software from last year which examined the different LE heaps. and: thank you, Allan Kielstra, for

Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

On Thu, May 11, 2017 at 4:55 PM, Bernd Oppolzer wrote: > Yes, of course. I detected the error when I looked at > my piece of software from last year which examined the different LE heaps. > > and: thank you, Allan Kielstra, for the clarification regarding Reg 12; > so

Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

Yes, of course. I detected the error when I looked at my piece of software from last year which examined the different LE heaps. and: thank you, Allan Kielstra, for the clarification regarding Reg 12; so my call to the ASSEMBLER function to get the address of the CEECAA will work? Here is the

Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

If a C or PL/I or COBOL (or any LE high level language) program calls an assembler program, it will have set GPR12 to the CEE Anchor correctly before making the call. Assuming that you are completely lost in space in LE and you need the CEE anchor, there is a service called CEEARLU. It is

Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

On Thu, 11 May 2017 15:27:38 -0500, Allan Kielstra wrote: >This statement: > >>>CEECSA is always address by reg 12, while inside a LE module. > >is not strictly true. GPR12 is only required to point to CEECSA on entry to >and exit from a procedure. Compilers are free to use GPR12 for whatever

Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

oh oh ... I did not take this into account ... I wrote a C program to get the HPCB addresses for Belowheap and Anyheap, and to get them, I needed the CEECAA, and I did this by looking at reg 12 using an ASSEMBLER subprogram: memset (rbuffer, 0x00, sizeof (rbuffer)); MDV9970 (rbuffer);

Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

This statement: >>CEECSA is always address by reg 12, while inside a LE module. is not strictly true. GPR12 is only required to point to CEECSA on entry to and exit from a procedure. Compilers are free to use GPR12 for whatever other purpose they chose at other program points. That means

AW: Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

> And I forgot to mention: > > CEECSA is always address by reg 12, while inside a LE module. ... and I forgot to thank you as well, Bernd -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access

AW: Re: JCL System symbols

> In the future, I encourage you to take the time to help yourself and presumably others by sending an appropriate email to the ID folks to ask for / suggest updates. Peter, I very much appreciate your effort. I know about the RCF process, and I have submitted quite some. If often heard that

Anybody using Zara with an IBM 7740?

Anybody using Zara with an IBM 7740? What level of Zara? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Interesting article in IBM System Magazine

On Thu, 11 May 2017 08:53:38 -0500, Tom Marchant wrote: >On Wed, 10 May 2017 23:37:31 -0500, Edward Gould wrote: > >>... > >Usually, a URL such as this can be truncated, deleting the "?" and everything >that follows. >

Re: AW: Re: job output into dataset

Hello All, Finally I have good news. Today we performed below steps. 1) I changed my message class z out disp parameter to write,write and then run spin command but still no oputut saved in output queue. 2) I restarted IMS address space and before running spin command against jesmsglg dd, I

Re: rename datasets

On Thu, 11 May 2017 08:40:47 -0500, Scott Barry wrote: > >Any datasets on tape or all DASD (any with more than 17 character tape dataset >name?) TMC consideration possibly depending on the tape management subsystem >(i.e., CA-1 has a utility but last 17 characters are recorded in the TMC)?

Re: How are Program Object sections with Defer attribute loaded?

The very first program I ever wrote for pay--when I graduated from street walking to hall walking--contained a huge number of full-word counters. It was, if I may say, a superb program, but a colleague wondered why I needed three base registers. Turns out that my computer-school assembler class

Re: rename datasets

Thanks a lot john . it worked . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: rename datasets

DASD vs. DISK vs. Migrated Should be DASD vs. TAPE vs. MIGRATED I do not think you can rename if the file is TAPE or Migrated. For Migrated you might need recalls Note: Depending on the number of datasets, you may wish to have SAY statements added SAY input-dsn IS BEING

Re: rename datasets

Since you have all the dataset names in a file already, it wouldn’t be too hard to do a little file tailoring, to code up a DFDSS job to do a copy with rename that deletes the old one afterwards similar to what Allan suggested. The beauty of that is that you then don’t care if it’s a flat

Re: Interesting article in IBM System Magazine

On Wed, 10 May 2017 23:37:31 -0500, Edward Gould wrote:

Re: rename datasets

You probably need to code an EXECIO to read the input file, then adjust the code. Remove the LISTC and just do the DO LOOP part I am sure when John sees this, he may post a version that meets your needs READ from INPUT File ALTER Names Though, depending on dataset types (DASD vs. DISK vs.

Re: rename datasets

On Thu, May 11, 2017 at 8:36 AM, Ron Thomas wrote: > Thanks John . I am new to Rexx , but just wanted to know how in the below > code, we make sure that only what is in my input file is read and renamed > and not all the datasets under the SLXR5V.SAPDB.* ? > ​Good catch. My

Re: rename datasets

On Wed, 10 May 2017 15:55:08 -0500, Ron Thomas wrote: >Also, all of the files that need to renamed is there in a file . We want only >those in the file to be renamed . > >Thanks >Ron T > Any datasets on tape or all DASD (any with more than 17 character tape dataset name?)

Re: rename datasets

Thanks John . I am new to Rexx , but just wanted to know how in the below code, we make sure that only what is in my input file is read and renamed and not all the datasets under the SLXR5V.SAPDB.* ? /* REXX */ XX=OUTTRAP('DATA.','*') LISTC LVL('SLXR5V.SAPDB​') XX=OUTTRAP("OFF") DO I=1 TO

Re: How are Program Object sections with Defer attribute loaded?

It appears to me that deferred-load sections are merely an enhanced external dummy section (aka pseudo-register) facility. The binder updates Q-cons for them, and it's up to the program to implement the actual in-memory version, and provide a method for finding it. LE and its HLL ancestors have

AW: Re: How are Program Object sections with Defer attribute loaded?

>>How does one request that "deferred load" section be >>loaded now? >"One" does not. LE does, using an internal interface. LE is responsible for making sure that both the "immediate load" and "deferred load" sections are in place. I understand LE is using it, but since "deferred load" is

Re: JCL System symbols

I suspect this is a consequence of a simple-minded symbol resolution facility that can't detect or report a buffer overrun when the length of a symbol's value exceeds the length of its name. The symbol substitution service (ASASYMBM) is indeed quite simple-minded. The choice to truncate in a

Re: How are Program Object sections with Defer attribute loaded?

>How does one request that "deferred load" section be >loaded now? "One" does not. LE does, using an internal interface. LE is responsible for making sure that both the "immediate load" and "deferred load" sections are in place. As to finding it in a dump, perhaps that would be based on

AW: Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

Many thanks for the details. Much appreciated. This information might be in the manuals, but it is a bit scattered. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to