AW: Re: Use of "trap" facility in z/OS?

[bernd.oppol...@t-online.de]

we did exactly the Same to a custumer specific Debugging Product some years 
ago (replacing x00 Breakpoints with trap2) and Made the Same experience: 
some Performance gains but not so much. for the Update of the duct our 
systems Folks wrote a Special svc for us which did only this, nothing Else.

Kind regards

Bernd



Gesendet mit der Telekom Mail App




--- Original-Nachricht ---
Von: Dave Cole
Betreff: Re: Use of "trap" facility in z/OS?
Datum: 22.06.2019, 9:23 Uhr
An: IBM-MAIN@listserv.ua.edu




FWIW: Around a year ago, z/XDC became a product that uses TRAP2. It
gives the user the option of using TRAP2 or X'00' opcodes for
breakpoints. It yields some performance improvement, but not as much
as I had hoped.

Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:  >
dbc...@colesoft.com 

Home page: www.colesoft.com 
LinkedIn: www.xdc.com 
Facebook: www.facebook.com/colesoftware

YouTube: www.youtube.com/user/colesoftware


Tools: z/XDC
z/XDC> for Assembler debugging
c/XDC
c/XDC>
for C debugging





At 6/21/2019 07:33 AM, John McKown wrote:
>On Thu, Jun 20, 2019 at 5:41 PM Chuck mailto:ch...@arneycomputer.com> > wrote:
>
>> > The TRAP Instructions work fine John. You have used a product that 
uses
>> > them.
>> >
>I do? I don't know which product that is. Or is "you" a generic in this
>case?
>
>
>
>> >
>> > Chuck Arney
>> >
>> >
>--
>Money is the root of all evil.
>Evil is the root of all money.
>With that in mind, money is made by the government ...
>
>Maranatha! <><
>John McKown

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

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

AW: Re: deduce program language

[bernd.oppol...@t-online.de]

i would Look if the c Program is Compiled with the Rent Option enabled. If 
so, simply calling at CEESTART will not Work.

Kind regards

Bernd



--- Original-Nachricht ---
Von: Brian Chapman
Betreff: Re: deduce program language
Datum: 02.10.2019, 16:27 Uhr
An: IBM-MAIN@listserv.ua.edu




@font-face { font-family: telegrotesk-medium_normal; src: 
url("file:///android_asset/fonts/telegrotesk_normal.ttf");}html,body { 
font-family: "telegrotesk-medium_normal"; font-size: medium; color: 
#4b4b4b; width: 100%;}

Don,

Thanks for the info. I'm familiar with the LE Vendor Interfaces, but I
guess I need to dig deeper.

With all of my test with COBOL and Assembler have been successful. However,
it always abends when I intercept a C program; usually with the CEE3550
message. Occasionally it is a 0C4 in the intended program.

Does LE have stricter requirements with CEESTART in C programs?


Thank you,

Brian Chapman


On Tue, Oct 1, 2019 at 1:23 PM Don Poitras  wrote:

> In article  t1cmgbfaka497yhff...@mail.gmail.com> you wrote:
> > I created a trace facility to intercept external interface calls (MQ,
> DB2,
> > IMS, etc) and dynamic calls.
> > For dynamic calls, I intercept the load request and replace the entry
> point
> > address with an entry point address of my own program. I then save the
> > original entry point address to later branch to the intended program. 
The
> > interception works for assembler and COBOL programs, but it fails for C
> > programs. When intercepting a C program, the process abends with a 4038
> > (CEE3550S The DLL cannot be loaded because it does not contain a
> CEESTART
> > CSECT).
> > Is there a write-up on how the program load point is mapped and how to
> > deduce the loaded program's language?
> > I hoped to clone my assembler intercept program and create a second 
copy
> > that includes the CEESTART macro to resolve this issue. However, I read
> > that the CEESTART, CEEMAIN, and CEEFMAIN should not be used within an
> > assembler program because it will produce unpredictable behavior. Must 
I
> > write a C program?
> > Thank you,
> > Brian Chapman
>
> I'm not sure how COBOL is working for you as it's an LE program the same
> as C, but perhaps you're not using standard LE DLL's for your COBOL
> programs. CEESTART is not a macro, it's a module/CSECT that gets linked
> from the LE bind library when you compile an LE program or DLL. It's
> always linked as the entry point as that's where the WSA is allocated
> and other housekeeping before the user code is called (either main() or
> the DLL function). LE doc is kind of spread all over the place, but
> for writing an assembler front-end as you're doing, I think the LE
> Vendor Interfaces book is something you should look at.
>
>
> 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ceev100/abstract.htm
>
> --
> Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
> sas...@sas.com (919) 531-5637 Cary, NC 27513
>
> --
> 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





Gesendet mit der Telekom Mail App


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

AW: Rexx SORT (was: ... Job Scheduler ... )

[bernd.oppol...@t-online.de]

http://bernd-oppolzer.de/blog_20150115_151000.htm
 .

this Contains a REXX Procedure
to sort a stem variable.
See quicksort_nonrec

hth

Kind regards

Bernd




--- Original-Nachricht ---
Von: Paul Gilmartin
Betreff: Rexx SORT (was: ... Job Scheduler ... )
Datum: 07.06.2017, 5:42 Uhr
An: IBM-MAIN@LISTSERV.UA.EDU





On Wed, 7 Jun 2017 00:33:30 +, Rob Schramm wrote:

>Address SORT
>
>is more what I was thinking. It is just such a commonly needed thing for
>simple sorts i.e.
>SORT 1 8 a
>
I'm guessing the arguments are a column range and Ascending?

>Guess I am just lazy/annoyed when it comes to things that I think should 
be
>provided.
>
This is too specialized for my taste. I could envision making every command
in the Utilities Ref. a command environment. I'd like something more 
general.
(But I'm inconsistent. I enthusiastically approve ADDRESS ISREDIT and
ADDRESS SDSF. But those environments are quasi-interactive: each subcommand
returns a status. DFSORT isn't like that.)

With Regina I can:
555 $ cat showsort.rex 
#! /usr/bin/rexx
signal on novalue

F1.1 = 'Larry'
F1.2 = 'Moe'
F1.3 = 'Curly'
F1.0 = 3

address SYSTEM 'sort' '-k1.1,1.8' with , /* Issue the 'sort' command. */
input stem F1. ,
output stem F2.

do I = 1 to F2.0
say I F2.I; end I

... and get output:
556 $ rexx showsort
1 Curly
2 Larry
3 Moe

ADDRESS WITH redirection seems to be an ANSI Rexx construct that IBM
has chosen not to implement:
http://www.rexxla.org/rexxlang/standards/j18pub.pdf


I could envision adapting it in TSO Rexx something like:
address LINKMVS 'ICEMAN' with ,
DD:SORTIN stem F1. ,
DD:SORTOUT stem F2.

-- gil

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

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

AW: Re: LE QuestionT

[bernd.oppol...@t-online.de]

First allocation in subpool 1,
secondary allocations in subpool 2.
this is true for heap and Stack
allocation.

I remember a very useful IBM presentation
on this topic which is titled "stacks are simple,
heaps are Fun". you will find it using Google

hth

Kind regards

Bernd






--- Original-Nachricht ---
Von: Charles Mills
Betreff: Re: LE QuestionT
Datum: 06.06.2017, 17:06 Uhr
An: IBM-MAIN@LISTSERV.UA.EDU





In-line.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of scott Ford
Sent: Tuesday, June 6, 2017 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LE QuestionT

> I need some help understanding LE and Cobol. I ran our Cobol STC with RPT 
options and STG options on, i see a large like 700K Heap size.

700K is not large these days LOL. I allocate 3MB on startup!

> My first question is where does LE place the HEAP ( what Subpool ) ?

Don't know but should be in the LE books. Above the 16MB line. I have a 
feeling of subpool zero but that may just be an assumption on my part.

> Secondly, is that HEAP storage freed anytime during the running of a STC 
written in COBOL ? We do not use CEEGTST , etc ...

You can control how that works, at least in C/C++. If you exhaust the heap 
it allocates more (and you can control the increment). You can control what 
happens if the heap contracts: is the storage freed, or kept around in case 
it is needed again, saving the overhead of another GETMAIN?

You can run a storage report at end of job to see if you have any leaks. 
You turn it on with a HEAPCHK statement in CEEOPTS DD. Makes things slow 
during testing.

CM

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

AW: Re: AW: Rexx SORT (was: ... Job Scheduler ... )

[bernd.oppol...@t-online.de]

May I suggest once again that you use
the quicksort Routine that I posted
Yesterday, using pure REXX?
you will see that it is very fast.
but: you have to use the
non recursive Variant, because
Most REXX Implementations
will be Limited on the number
of call Levels

Kind regards

Bernd




--- Original-Nachricht ---
Von: Nims,Alva John (Al)
Betreff: Re: AW: Rexx SORT (was: ... Job Scheduler ... )
Datum: 08.06.2017, 14:59 Uhr
An: IBM-MAIN@LISTSERV.UA.EDU





No, z/OS REXX does not have a SORTSTEM function built-in. I currently have 
a STEMSORT function, but it is from a 3rd party vendor.

Al Nims
Systems Admin/Programmer 3
UFIT
Universtiy of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Tony Thigpen
Sent: Thursday, June 08, 2017 4:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AW: Rexx SORT (was: ... Job Scheduler ... )

Could you point me to the REXX list?

Also, we have had a SORTSTEM function in VSE REXX for a LONG time. Does 
z/OS not have SORTSTEM?

Tony Thigpen

Nims,Alva John (Al) wrote on 06/07/2017 01:27 PM:
> This is getting to be like a discussion that was had on the REXX list 
recently, as in it would be nice if there was an available PIPE type of 
command available, oh wait there is:
>
> The product where IBM has made a PIPE command available:
> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd&subtype
 =
> sm&htmlfid=897/ENUS5655-D45
>
> Sorting is very simple there:
> PIPE stem xy. | sort 1 5 | stem yx.
> Or PIPE < indsn | sort 1 5 | > outdsn
>
> These are simple examples and not everything that can be done, but when I 
was using it (my previous job) it was reasonably quick in execution. Now I 
have to do the allocation of SORTIN, SORTOUT and SYSIN (control cards) then 
invoke SORT, very cumbersome compared to the simple PIPE command version.
>
> Al Nims
> UFIT
> University of Florida
> (352) 273-1298
> @Home
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Elardus Engelbrecht
> Sent: Wednesday, June 07, 2017 1:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AW: Rexx SORT (was: ... Job Scheduler ... )
>
> Paul Gilmartin wrote:
>
>> Bernd.Oppolzer wrote:
>>> http://bernd-oppolzer.de/blog_20150115_151000.htm

>>> this Contains a REXX Procedure to sort a stem variable. See
>>> quicksort_nonrec
>> o Of course. But why should it be necessary to reinvent the wheel when 
DFSORT has vast capabilities not practical to duplicate in Rexx?
>
> Could you please be kind to tell us what function(s) you have in mind?
>
> On one side, REXX has this nice PARSE function. hard to duplicate that in 
DFSORT, but do-able.
> On other side, DFSORT handles SMF records and their weird timestamps
> better. (Yes, I know REXX can handle VBS records these days.)
>
>
 I could envision adapting [the ANSI Rexx form] in TSO Rexx something 
like:
 address LINKMVS 'ICEMAN' with ,
 DD:SORTIN stem F1. ,
 DD:SORTOUT stem F2.
>
> You can do the same with REXX statements like this:
>
> "ALLOC F(SORTIN) blah "
> "EXECIO * DISKR SORTIN (STEM F1. FINIS"
> "FREE F(SORTIN)"
> ... and then call DFSORT and sort out your magic
>
> In fact, I have some RYO REXX progs which call DFSORT to sort something 
out...
>
>
>> o And while I chose SORT as an example, I intended to consider a more 
general solution. Imagine a facility that could invoke not only SORT, but:
>> - IEBUPDTE witn SYSIN, SYSUT1, and SYSUT2 assigned to stems.
>> - ISRSUPC with OLD, NEW, and DELTA assigned to stems.
>> - Etc. Much like ANSI Rexx.
>
> You can invoke anything with REXX including SDSF, IEBGENER, IEBCOPY, etc. 
as long you pass/receive parameters and DD correctly.
>
> In fact, zSecure ISPF panels are mostly driven by REXX.
>
> But, I agree with you, something standardised so you can do what you 
desire would really be useful.
>
> Something like "ALLOC F(SYSIN)  ..."
>
> Also FREE(FSYSIN) which -optionally- drops those Stems. (I said
> optionally, because, you may need to free up SYSIN immediately, but
> continue to handle those stems.)
>
> Just some little idle ideas, ya ;-)
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> 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 lis

AW: Re: Why would LE not trap?

[bernd.oppol...@t-online.de]

is it possible to Set the Amode to 31 in the estae Routine? the estae 
Routine should be able to detect that the Problem occured while executing 
in Amode 64??



Gesendet mit der Telekom Mail App




--- Original-Nachricht ---
Von: Charles Mills
Betreff: Re: Why would LE not trap?
Datum: 27.08.2017, 18:59 Uhr
An: IBM-MAIN@LISTSERV.UA.EDU





Well, I now know a little more and am a little mystified.

I had this sudden thought that perhaps the difference at the one customer
was that the two S0C4's we have experienced there would have happened in
assembler code running AMODE 64. (The C++ code is all AMODE 31.) So today I
coded up some test code to force a S0C4 in AMODE 64 and sure enough, same
results, system SYSUDUMP, no LE recovery.

I added some debugging WTOs to the ESTAE recovery so I could see what was
happenning. My ESTAE recovery routine is getting driven. I am (as intended)
percolating. LE's recovery routine -- which admittedly I am abusing a bit 
--
apparently is boggled by AMODE 64 and is in turn percolating to MVS. That 
at
least would explain what I am seeing.

So my questions today to this august group are

1. In what AMODE will a recovery routine be entered if the ESTAE was issued
in AMODE 31 but the exception happened in AMODE 64? I don't see that in the
manuals. (It's probably there -- I just don't see it.)
2. If the answer to (1.) is AMODE 64, how do I change that? I tried SETRP
RETRYAMODE=31 but got an MNOTE that it was invalid with Percolate (and
admittedly, the parameter is RETRYAMODE, not PERCOLATEAMODE -- it is for
retry, not percolation).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, August 25, 2017 4:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Why would LE not trap?

I have a C++ program compiled with

#pragma runopts( POSIX(ON),TRAP(ON,NOSPIE),NOEXECOPS )

I have my own ESTAEX. On an ABEND, if SDWACLUP is not set, I percolate,
presumably to LE's ESTAE and it drives my C Signal catcher.

It works. In testing, and at most customers, a S0Cx drives the Signal
routine, 100% of the time.

But one customer has twice gotten a S0C4 and in both cases we got an
old-fashioned SYSUDUMP with no Signal. I don't know if we came through the
ESTAEX exit or not. The ESTAE exit logic is not at all complex so some
subtle bug is unlikely. The reported S0C4 is in the main logic, not in the
ESTAE recovery. The fact that it is consistent at one customer leads me to
think it is an environmental factor, not a logic error.

There are no LE options in PARM= or CEEOPTS.

Environment is STC, current release of z/OS (not sure exact version but
probably V2R1).

What should I be looking for? What would effectively override TRAP(ON)?
Would SDWACLUP ever be set on a vanilla S0C4?

It's at a customer and the S0C4 is extremely infrequent so "try this/try
that" is not an option. Why my own ESTAE? So I can deal with unrecoverable
ABENDs, which LE will not. Why NOSPIE? So everything comes through the
ESTAE.

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

AW: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[bernd.oppol...@t-online.de]

is my understsnding correct that the LE Error handler is activated but has 
Problems because of the 64 Bit Situation in the Ceecib and then the non 
handled 0c4 occurs? If so, would it help if you used your own LE Error 
handler? or modify the Ceecib contents in a sensible way before percolating 
to LE?



Gesendet mit der Telekom Mail App




--- Original-Nachricht ---
Von: Charles Mills
Betreff: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
Datum: 27.08.2017, 20:02 Uhr
An: IBM-MAIN@LISTSERV.UA.EDU





Starting a new thread. Here is the fundamental problem. (If you were
following the other thread -- I am now testing without my own ESTAE, just
vanilla LE.)

An AMODE 31 C++ program provides a signal handler. It will get driven for
your basic S0C1 or S0C4.

But if the C++ program calls an assembler subroutine that gets a S0C4 while
in AMODE 64 it seems to boggle LE and the signal routine is not driven.

At least that is what I am seeing. Does anyone know of a way to get LE to
drive an AMODE 31 C/C++ signal routine even if the exception occurred in
AMODE 64?

Charles

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

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[bernd.oppol...@t-online.de]

it was 2005 ca., when we decided at my Former customer's Site to replace 
the four or five different Abend Handling and dump printing Routines by 
one. The Input was different, the Output should be the Same. only one of 
the Input Variants then Had 32 Bit Registers, all others were alresdy 64. 
Of course, we Always showed 64 Bit register contents, when possible.



Gesendet mit der Telekom Mail App




--- Original-Nachricht ---
Von: Charles Mills
Betreff: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 
assembler?
Datum: 28.08.2017, 15:15 Uhr
An: IBM-MAIN@LISTSERV.UA.EDU





I can see all 64 bits in the SDWA.
CharlesSent from a mobile; please excuse the brevity.
 Original message From: Steve Smith  
Date: 8/28/17 8:47 AM (GMT-05:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 
Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
I can only guess that this particular register dump comes from a
32-bit savearea.  Deliberately masking off the high-halves when
available would be profoundly asinine.  Say it ain't so, LE!

sas

On Sun, Aug 27, 2017 at 5:01 PM, Charles Mills 
> ; wrote:
...
>
> LE fails to print the high register halves, for example
>
> GPR0. _00C6  GPR1. _0020  GPR2. 
_  GPR3. _0002
>
> If I had nothing better to do I would open an RFE on that. Even assuming 
AMODE 31, how can LE assume that the high halves of the registers are of no 
debugging value? 64-bit register arithmetic -- or even using the high 
halves of registers as a temporary holding area -- is a valid technique 
even in the absence of AMODE 64. The C/C++ compiler itself does so.
>

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

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[bernd.oppol...@t-online.de]

some years ago I Had to call a openssl library from Pl/1. the Openssl 
library was compiled using XPlink (31 Bit). it worked in the End. the only 
Problem was that there Had to be a Interface Module doing a dynamic fetch 
on the XPlink object, because static linkage was Not possible. And Posix 
(on) was needed. But No Problems with Switching enclaves etc.



Gesendet mit der Telekom Mail App




--- Original-Nachricht ---
Von: John McKown
Betreff: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 
assembler?
Datum: 29.08.2017, 17:34 Uhr
An: IBM-MAIN@LISTSERV.UA.EDU





On Tue, Aug 29, 2017 at 10:28 AM, Don Poitras 
> ; wrote:

> But you _can_ address data above the bar in "pure" C. Just compile and 
link
> the C code as 64-bit.
>

I've no experience, but from what I've read, this is "CPU costly" in that
the 31 bit C is running in a "normal" (non-XPLINK) LE enclave whereas 64
bit C _must_ run in an XPLINK LE enclave. Starting and stopping the XPLINK
LE enclave is "expensive", again from what I've read. Of course, with some
hard work, I think it might be possible to use a CEEPIPI to create and
maintain an XPLINK 64 bit LE enclave and dynamically swap between the LE
enclaves.

--
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

Maranatha! <><
John McKown

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

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

AW: COBOL 2014 dynamic capacity tables

[bernd.oppol...@t-online.de]

No, I don't instrument at all. 

I use my knowledge of the LE heap implementation (see the presentation
mentioned below) to store a map of all allocated and free areas at a given time
(area adresses and lengths) and then - some microseconds later - I compare that 
with the new image then. Then I build a delta listing which shows all the areas
that have changed in the meantime, that is, which have been allocated and not 
freed. 

If you call this before and after a critical function, you will see exactly
what areas are left "unfreed" by this function. This proved to be very 
helpful in our environment, especially if the critical function is written 
by another team. (I don't need to "instrument" the functions of the foreign 
team). 

Kind regards

Bernd



-Original-Nachricht-
Betreff: Re: COBOL 2014 dynamic capacity tables
Datum: 2016-08-09T13:53:15+0200
Von: "David Crayford" 
An: "IBM-MAIN@LISTSERV.UA.EDU" 

I  use the HEAPCHK(ON,1,0,10,10) LE runtime option to find my memory 
leaks. How is your instrumentation different? I assume you wrap 
malloc()/free() calls?


On 9/08/2016 1:50 AM, Bernd Oppolzer wrote:
> IMO there is no need to create additional heaps
> to support dynamic tables in COBOL.
>
> I did some research some days ago on the LE heap
> implementation and found an old IBM presentation (from 2005) on
> this topic called "Stacks and Heaps" (you will find it using
> Google, the full title reads something like "Stacks are easy,
> heaps are fun"). There are COBOL examples included, which
> use the LE functions CEEGTST (get storage) and CEEFRST
> (free storage) - I hope, I recall the names correctly.
>
> Based on these functions (which are malloc and free, after all),
> you could do all sorts of dynamic allocations from COBOL, using
> the normal LE "user heap", which is sufficient, IMO.
>
> BTW: I wrote some functions in the last few days, which dumps all
> the allocated heap areas and - more interesting - they write reports,
> how the heap has changed since the last call. This is very interesting 
> ...
> if you have a function that you think that does not free its heap areas
> properly, you can call this heap report function before and after
> this function call and find out by looking at the so called heap delta 
> listing.
>
> If you are interested, feel free to contact me offline.
>
> Kind regards
>
> Bernd
>
>


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

AW: Converson of hex value to character

[bernd.oppol...@t-online.de]

Thank you very much ... 

BTW: I'm doing ASSEMBLER classes and training in Germany since 1985
for large companies of the financial sector, but in the last years there was 
not 
much need for this. But there should be, IMO, because there are still many 
ASSEMBLER programs running, and the maintenance (and migration, maybe) 
cannot all be done by us oldtimers - I'm only 57 :-) ... recently I was called 
for a mainframe project here in Germany, and I was the youngest candidate !!
The ages spanned from 57 to 73. 

and so we should try to teach ASSEMBLER etc. to young people, too. 

So: if you plan a project to teach ASSEMBLER to some younger people 
in your company somewhere in Europe, please call me; I would like 
to support you doing this. 

At the moment I'm working at a project in the financial area, which uses 
C and PL/1 (and DB2), but doing an ASSEMBLER teaching project 
in between should not be a problem at all. 

Kind regards

Bernd



-Original-Nachricht-
Betreff: Re: Converson of hex value to character
Datum: 2016-09-13T14:41:52+0200
Von: "Steve Smith" 
An: "IBM-MAIN@LISTSERV.UA.EDU" 

Bernd Oppolzer's answer is the best, 
...

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