[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Invalid heap space using HTTPAPI
Mike:
I am sending you the source file of TSTPHONES and the copies.
I did run the SQL:
Select ptptrhx, count(*) from PTRTOHEXF where ptboa in ('A','B') group
by ptptrhx having mod(count(*),2)<>0
I got the following results:
POINTER IN HEX COUNT ( * )
C37158C036F05C40 1
EFF2BA445DB10640 3
C373B57A1247F000 5
EFF2BA445D5912B0 1
F9B1EFB0BB3BA350 3
C373B57A120F9750 5
C373B57A1270A940 1
EBBC3D27F7AD2070 3
FAB240A7E34CF390 3
FAB240A7E3671E60 1
EFF2BA445D51B410 1
F9B1EFB0BB32B620 1
C373B57A12CB2860 3
EFF2BA445DBF7490 1
E6B18C7D49B88480 25
E6F0BB020455BEB0 5
C37158C036C445F0 1
C373B57A120E4660 47
D87005004EDC34B0 33
E6B18C7D49AC06E0 5
E6F0BB0204F4D3A0 3
F34594020EF54BB0 3
C373B57A12AC6180 25
C373B57A123C9000 15
E6F0BB02044653F0 3
D0D42C3D35F080A0 1
D0D42C3D35180C00 1
EFF2BA445DD2AB90 5
C37158C036AE4E10 1
E6F0BB0204DCF2B0 3
D87005004E521CC0 5
EBBC3D27F78D6000 1
EFF2BA445D4D8C60 1
E6F0BB0204AC31A0 1
F9B1EFB0BBA43220 3
F9B1EFB0BB0B7420 1
C37158C03688C160 9
F9B1EFB0BB4C6DE0 1
E6B18C7D491D86C0 3
F34594020ED01330 1
C37158C03621DE10 1
D0D42C3D355CA490 1
E6F0BB0204B01600 1
E6F0BB02049A6B40 9
FAB240A7E35BB310 1
F34594020EC8CCA0 3
F9B1EFB0BB24BFA0 3
C47EA929DB79E8C0 9
F9B1EFB0BB79EE40 1
EBBC3D27F7179D60 1
... More
If I select one of the groups (E6B18C7D49B88480), you see
allocate(B)/deallocate(A) in order, but some of them stay allocated as
this one:
BEFORE/AFTER POINTER IN HEX TIMESTAMP
B E6B18C7D49B88480 2011-03-02-11.45.42.517000
A E6B18C7D49B88480 2011-03-02-11.45.42.615000
B E6B18C7D49B88480 2011-03-02-11.45.42.773000
A E6B18C7D49B88480 2011-03-02-11.45.42.863000
B E6B18C7D49B88480 2011-03-02-11.45.43.030000
A E6B18C7D49B88480 2011-03-02-11.45.43.246000
B E6B18C7D49B88480 2011-03-02-11.45.43.363000
A E6B18C7D49B88480 2011-03-02-11.45.43.576000
B E6B18C7D49B88480 2011-03-02-11.45.43.641000
A E6B18C7D49B88480 2011-03-02-11.45.43.711000
B E6B18C7D49B88480 2011-03-02-11.45.43.821000
A E6B18C7D49B88480 2011-03-02-11.45.43.891000
B E6B18C7D49B88480 2011-03-02-11.45.43.990000
A E6B18C7D49B88480 2011-03-02-11.45.44.060000
B E6B18C7D49B88480 2011-03-02-11.45.44.162000
A E6B18C7D49B88480 2011-03-02-11.45.44.232000
B E6B18C7D49B88480 2011-03-02-11.45.44.349000
A E6B18C7D49B88480 2011-03-02-11.45.44.419000
B E6B18C7D49B88480 2011-03-02-11.45.44.525000
A E6B18C7D49B88480 2011-03-02-11.45.44.595000
B E6B18C7D49B88480 2011-03-02-11.45.44.670000
A E6B18C7D49B88480 2011-03-02-11.45.44.739000
B E6B18C7D49B88480 2011-03-02-11.45.45.153000
A E6B18C7D49B88480 2011-03-02-11.45.45.287000
B E6B18C7D49B88480 2011-03-02-11.45.45.321000
If I do the following SQL to see how many pointers stay allocated and
not deallocated:
select * from (
select * from iier00vw/ptrtohexf where ptboa='B') as B
left join (
select * from iier00vw/ptrtohexf where ptboa='A') as A
on A.ptptrhx = B.ptptrhx
where A.ptptrhx is null
I got 1,353,878 records:
BEFORE/AFTER POINTER IN HEX TIMESTAMP BEFORE/AFTER
POINTER IN HEX TIMESTAMP
B E6F0BB0204003A00 2011-03-02-08.49.04.545000 -
- -
B E6F0BB0204004010 2011-03-02-08.49.06.247000 -
- -
B E6F0BB020401AF30 2011-03-02-08.49.06.252000 -
- -
B E6F0BB020402D910 2011-03-02-08.49.06.259000 -
- -
B E6F0BB0204040300 2011-03-02-08.49.06.266000 -
- -
B E6F0BB0204045700 2011-03-02-08.49.06.270000 -
- -
B E6F0BB02040598F0 2011-03-02-08.49.06.327000 -
- -
B E6F0BB020406C380 2011-03-02-08.49.06.338000 -
- -
B E6F0BB020407ED10 2011-03-02-08.49.06.342000 -
- -
B E6F0BB02040807A0 2011-03-02-08.49.06.459000 -
- -
B E6F0BB0204085800 2011-03-02-08.49.11.184000 -
- -
B E6F0BB02040881D0 2011-03-02-08.49.11.192000 -
- -
B E6F0BB020408ABB0 2011-03-02-08.49.11.203000 -
- -
B E6F0BB0204003F40 2011-03-02-08.49.11.209000 -
- -
B E6F0BB02040882D0 2011-03-02-08.49.11.288000 -
- -
B E6F0BB0204081610 2011-03-02-08.49.11.306000 -
- -
B E6F0BB020407EC10 2011-03-02-08.49.11.312000 -
- -
B E6F0BB020407ECA0 2011-03-02-08.49.11.324000 -
- -
B E6F0BB020409C020 2011-03-02-08.49.11.349000 -
- -
...more
Then I tried the following to check how many were tried to deallocated
than were not allocated and I got NONE.
select * from (
select * from iier00vw/ptrtohexf where ptboa='B') as B
left join (
select * from iier00vw/ptrtohexf where ptboa='A') as A
on A.ptptrhx = B.ptptrhx
where B.ptptrhx is null
For me it looks there are a number of pointers not deallocated from
memory that grows and grows and create the problem.
The question is why the error occurs in the dealloc and not in the
alloc.
I am still confused.
Regards,
JULIO C. CABRERA
Sr. Programmer Analyst, Information Technology
Interval International
6262 Sunset Drive * Miami, Florida 33143
305.666.1861, ext. 7287 * direct 305.925.7287
cell 305.928.7925* fax 305.668.3409
Julio.Cabrera@xxxxxxxxxxxxxxxx
IntervalWorld.com * ResortDeveloper.com
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mike Krebs
Sent: Wednesday, March 02, 2011 1:20 AM
To: HTTPAPI and FTPAPI Projects
Subject: RE: Invalid heap space using HTTPAPI
Hi,
We are getting closer?
Someone with more knowledge of pointers will have to tell me if
X'8000000000000000F5BC674142E6B960' is a valid pointer. Is the 8 to
start the pointer correct? Looks like the pointers in your case are
twice as big as what you put in the file.
I didn't see F5BC674142E6B960 in your PtrToHexFile.doc. Where did that
pointer come from?
Odd how several pointers are allocated then some other number are
deallocated. If you run an SQL across your pointer file something like
Select ptptrhx, count(*) from PTRTOHEXF where ptboa in ('A','B') group
by ptptrhx having mod(count(*),2)<>0
Do you get any records? I would think you should only have a very few
(if any) from the end of the list.
Could you post just the source for your test program please?
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-
> bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Julio Cabrera
> Sent: Tuesday, March 01, 2011 2:09 PM
> To: HTTPAPI and FTPAPI Projects
> Cc: Jason Christman
> Subject: RE: Invalid heap space using HTTPAPI
>
>
> Mike:
>
> Sorry I wait so long to answer your email. I was debugging an testing
> to
> try to find a cure for the patient (as you said) and doing it step by
> step.
> Let me first answer your questions about the error:
>
> 1. If you run this for the record at 176,677, do you get the error?
> No. This error happens only when a big amount of information is
> read.
> Not always happens at the same record.
> 2. If you read the first 1000 records without calling getContactInfo,
> then let it run, do you get the error at 177,677?
> No. I get it 1000 records or more after the 177,677
> 3. Does it always crash after running 176,677 iterations regardless of
> the data you reading?
> No. It happens at different times, depending the data.
> 4. If you watch the program running, do you notice anything unusual?
> Stack growing? Files growing?
> None of them. There is nothing unusual, stack and files stays
> the same. I ran it interactive and in batch and the results are the
> same.
> 5. Did you dump the program? Program dump listing?
> Yes I did dump the program, but the only program I can dump is
> WS.CONTAC and the error happens in the module HTTPUTILR4, which I
> could'nt dump. The error send me to WS.CONTAC.
>
> Now, lets go to the debug steps.
>
> 1. I download the beta version of HTTP API library (HTTPAPI
> Ver1.24beta11 released 2010-09-09) and installed it in LIBHTTPB
> I just compile my service program for the WS objects to use
> LIBHTTPB.
> Then I ran the program and I did NOT get the error. Try batch
> and iteractive 3 times. It read more than 300,000 records and NO
> error.
>
> 2. We have Fulfillment program that consume different web services:
> WS.EMAIL and WS.PHONES. And we were having the same problem that the
> other one (WS.CONTACT). I ran the program with the HTTP beta version
> and I got the heap memory error.
> I attached Fulfillment_Email_heap_memory_error_Using_LIBHTTPB
> The program is a complicate fulfillment process, but I recreate
> the problem using a test program (TSTPHONES) - the compiled version
> and the Heap memory error are attached. The 2 compile sources for
> the consuming Web Services are also attached.
>
> 3. I modified the module LIBHTTPB/HTTPUTILR4 where the error
> happens, and add a call after the pointer is allocated and after
> the pionter is deallocated. See attached file Call PTRTOHEX in
> HTTPUTILR4.
> This program just write the hex value of the pointer in a file.
> I am sending you also the last records I get for the process.
>
> I really do not know what else to do. May be with this information you
> see something that I cannot see.
> I appreciate your help
>
> Regards,
>
> JULIO C. CABRERA
> Sr. Programmer Analyst, Information Technology
> Interval International
> 6262 Sunset Drive * Miami, Florida 33143
> 305.666.1861, ext. 7287 * direct 305.925.7287
> cell 305.928.7925* fax 305.668.3409
> Julio.Cabrera@xxxxxxxxxxxxxxxx
>
> IntervalWorld.com * ResortDeveloper.com
>
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mike Krebs
> Sent: Thursday, February 17, 2011 7:20 PM
> To: HTTPAPI and FTPAPI Projects
> Subject: RE: Invalid heap space using HTTPAPI
>
> Thanks for finally sending some almost useful information!
>
> Make only one change a time and test so we know what eventually cures
> the patient.
>
> You are running an old version. You really should be able to run this
> (especially in a test environment) with the latest version. As has
been
> pointed out, backwards compatibility is very good. At least run a test
> WS.CONTACT with the new version so that we know it is a current
> problem.
> Download the Beta and install into a different library. Compile and
run
> using the new version.
>
> >From limited experience, changing ptr between alloc and dealloc will
> cause a problem. If that happens, why?
>
> Did you dump the program? Program dump listing? Not sure it would
help,
> but can't hurt when debugging. What is the value of "ptr"?
>
> Is there a pointer declared in your module WS.CONTACT called "ptr"?
Are
> you using it? I don't think it needs to be there. If not, please
delete
> and retry test.
>
> Add some debugging output...print the ptr value at the point where it
> allocates memory. Print it just before the dealloc. The pointer should
> be the same. Here is an article that talks about one way to print a
> pointer http://www.itjungle.com/fhg/fhg110310-story02.html. HTTPAPI is
> full of pointers and uses arrays of pointers in some places.
>
> If you run this for the record at 176,677, do you get the error?
>
> If you read the first 1000 records without calling getContactInfo,
then
> let it run, do you get the error at 177,677? In other words, does it
> always crash after running 176,677 iterations regardless of the data
> you
> reading? Or at least within a few records of that?
>
> If you watch the program running, do you notice anything unusual?
Stack
> growing? Files growing?
>
> Good of you to send a compile listing for the code so we can see the
> file layouts and other copied information...if want us to try to
> recreate, we also need just the source without the other stuff and
> maybe
> just a bit of knowledge on how to fake it. But try the new version,
try
> the ptr removal, try printing the ptr. Let's see how far we get.
>
>
> > -----Original Message-----
> > From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-
> > bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Julio Cabrera
> > Sent: Thursday, February 17, 2011 11:00 AM
> > To: HTTPAPI and FTPAPI Projects
> > Subject: RE: Invalid heap space using HTTPAPI
> >
> > Charles:
> >
> >
> >
> > After a while trying to reproduce the error, I wrote a program
> > (TSTCONTACT) that reads our member file with almost 5 million
records
> > in
> > a loop and call my program getContactInfo. After 176,677 records, it
> > gives the heap memory error:
> >
> >
> >
> >
> >
> > The error happens in the dealloc line (3448):
> >
> >
> >
> > Program: HTTPAPIR4 Library: LIBHTTP Module:
> > HTTPUTILR4
> >
> >
> > 3444 3443 D xdealloc PI
> >
> >
> > 3445 3444 D ptr *
> >
> >
> > 3446 3445 /if defined(TERASPACE)
> >
> >
> > 3447 3446 /else
> >
> >
> > 3448 3447 C dealloc ptr
> >
> >
> > 3449 3448 /endif
> >
> >
> > 3450 3449 C eval ptr = *null
> >
> >
> > 3451 3450 P E
> >
> >
> > 3452 3451
> >
> >
> > 3453 3452
> >
> >
> > 3454 3453
> > *++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > 3455 3454 * xrealloc(): re-allocate memory
> >
> >
> > 3456 3455
> > *++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > 3457 3456 P xrealloc B export
> >
> >
> > 3458 3457 D xrealloc PI *
> >
> >
> >
> >
> > The http_debug was *ON
> >
> > I include here the source of the Test program, The source of the RPG
> to
> > consume the Web Service and the txt of the debug.
> >
> > I still do not have any clue of what happened.
> >
> > I will appreciate if you can give me any idea.
> >
> >
> >
> > Thank you very much,
> >
> >
> >
> >
> >
> > JULIO C. CABRERA
> >
> > Sr. Programmer Analyst, Information Technology
> >
> > Interval International
> >
> > 6262 Sunset Drive * Miami, Florida 33143
> >
> > 305.666.1861, ext. 7287 * direct 305.925.7287
> >
> > cell 305.928.7925* fax 305.668.3409
> >
> > Julio.Cabrera@xxxxxxxxxxxxxxxx
> >
> >
> >
> > IntervalWorld.com * ResortDeveloper.com
> >
> >
> >
> > -----Original Message-----
> > From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> > [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Charles
> > Wilt
> > Sent: Friday, January 21, 2011 3:02 PM
> > To: HTTPAPI and FTPAPI Projects
> > Subject: Re: Invalid heap space using HTTPAPI
> >
> >
> >
> > Julio,
> >
> >
> >
> > Turn debug logging on and post the resulting log..
> >
> >
> >
> > http_debug(*ON);
> >
> >
> >
> > Charles
> >
> >
> >
> > On Fri, Jan 21, 2011 at 2:42 PM, Julio Cabrera
> >
> > <Julio.Cabrera@xxxxxxxxxxxxxxxx> wrote:
> >
> > >
> >
> > >
> >
> > > Gentlemen:
> >
> > >
> >
> > >
> >
> > > I need help with this error.
> >
> > >
> >
> > > It is happening with an RPG service using HTTPAPI, and normally
> >
> > > happens when the web service is called multiple times.
> >
> > >
> >
> > >
> >
> > > [cid:image002.jpg@01CBB979.7E576830]
> >
> > >
> >
> > >
> >
> > > Any help will be very appreciated.
> >
> > >
> >
> > >
> >
> > > Thanks,
> >
> > >
> >
> > >
> >
> > >
> >
> > > JULIO C. CABRERA
> >
> > >
> >
> > > Sr. Programmer Analyst, Information Technology
> >
> > >
> >
> > > Interval International
> >
> > >
> >
> > > 6262 Sunset Drive o Miami, Florida 33143
> >
> > >
> >
> > > 305.666.1861, ext. 7287 o direct 305.925.7287
> >
> > >
> >
> > > cell 305.928.7925 o fax 305.668.3409
> >
> > >
> >
> > > [1]Julio.Cabrera@xxxxxxxxxxxxxxxx
> >
> > >
> >
> > >
> >
> > > IntervalWorld.com o ResortDeveloper.com
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> ______________________________________________________________________
> >
> > > _______
> >
> > > Scanned by IBM Email Security Management Services powered by
> >
> > > MessageLabs. For more information please visit
> > http://www.ers.ibm.com
> >
> > >
> >
> ______________________________________________________________________
> >
> > > _______
> >
> > >
> >
> > > References
> >
> > >
> >
> > > 1. mailto:Julio.Cabrera@xxxxxxxxxxxxxxxx
> >
> > >
> >
> > >
> >
>
-----------------------------------------------------------------------
> >
> > > This is the FTPAPI mailing list. To unsubscribe, please go to:
> >
> > > http://www.scottklement.com/mailman/listinfo/ftpapi
> >
> > >
> >
>
-----------------------------------------------------------------------
> >
> > >
> >
> > >
> >
> >
>
-----------------------------------------------------------------------
> >
> > This is the FTPAPI mailing list. To unsubscribe, please go to:
> >
> > http://www.scottklement.com/mailman/listinfo/ftpapi
> >
> >
>
-----------------------------------------------------------------------
> >
> >
> >
> >
>
_______________________________________________________________________
> > _
> > _____
> >
> > Scanned by IBM Email Security Management Services powered by
> > MessageLabs.
> >
> >
>
_______________________________________________________________________
> > _
> > _____
> >
> >
> >
>
_______________________________________________________________________
> > ______
> > Scanned by IBM Email Security Management Services powered by
> > MessageLabs. For more information please visit
http://www.ers.ibm.com
> >
>
_______________________________________________________________________
> > ______
>
-----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
>
-----------------------------------------------------------------------
>
>
_______________________________________________________________________
> _
> _____
> Scanned by IBM Email Security Management Services powered by
> MessageLabs.
>
_______________________________________________________________________
> _
> _____
>
>
_______________________________________________________________________
> ______
> Scanned by IBM Email Security Management Services powered by
> MessageLabs. For more information please visit http://www.ers.ibm.com
>
_______________________________________________________________________
> ______
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
________________________________________________________________________
_____
Scanned by IBM Email Security Management Services powered by
MessageLabs.
________________________________________________________________________
_____
_____________________________________________________________________________
Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com
_____________________________________________________________________________
ÿþ 5 7 2 2 W D S V 5 R 4 M 0 0 6 0 2 1 0 S E U S O U R C E L I S T I N G 0 3 / 0 2 / 1 1 0 8 : 3 6 : 5 0 I I M I A D E V P A G E 1
S O U R C E F I L E . . . . . . . I I E R 0 0 V W / Q R P G M O D
M E M B E R . . . . . . . . . T S T P H O N E S
S E Q N B R * . . . + . . . 1 . . . + . . . 2 . . . + . . . 3 . . . + . . . 4 . . . + . . . 5 . . . + . . . 6 . . . + . . . 7 . . . + . . . 8 . . . + . . . 9 . . . + . . . 0
1 0 0 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * 1 2 / 0 7 / 0 9
2 0 0 * - T e s t B a s i c C o n t a c t W e b S e r v i c e f o r h e a p e r r o r - * 0 2 / 1 0 / 1 1
3 0 0 * - - * 1 2 / 0 7 / 0 9
4 0 0 * - - * 1 2 / 0 7 / 0 9
5 0 0 * - D a t e U s e r I D T a s k # D e s c r i p t i o n - * 1 2 / 0 7 / 0 9
6 0 0 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * 1 2 / 0 7 / 0 9
8 0 0 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * 1 2 / 0 7 / 0 9
1 0 0 0 F m e m b e r i f e k d i s k 0 2 / 1 0 / 1 1
1 1 0 0 D # o S 9 S 0 i n z ( 0 ) 0 2 / 1 0 / 1 1
1 1 0 1 0 0 M H D M e m N u m S 7 S 0 I n z 0 2 / 2 5 / 1 1
1 1 0 2 0 0 M H D W r k E m a i l S 1 0 0 A I n z 0 2 / 2 5 / 1 1
1 2 0 0 0 1 / 0 8 / 1 0
1 2 0 1 0 0 M H / D e f i n e C p y G e t E m a i l _ P r o t o t y p e 0 2 / 2 5 / 1 1
1 2 0 2 0 0 M H / C o p y * l i b l / Q R P G L E S R C , C p y E m a i l 0 2 / 2 5 / 1 1
1 2 0 3 0 0 M H / U n d e f i n e C p y G e t E m a i l _ P r o t o t y p e 0 2 / 2 5 / 1 1
1 2 0 4 0 2 / 2 5 / 1 1
1 2 0 5 0 4 0 2 / D e f i n e c p y _ g e t P h o n e B y T y p e _ P r o t o t y p e 0 2 / 2 5 / 1 1
1 2 0 6 0 4 0 2 / c o p y Q r p g l e s r c , C B . P h o n e s 0 2 / 2 5 / 1 1
1 2 0 7 0 4 0 2 / U n d e f i n e c p y _ g e t P h o n e B y T y p e _ P r o t o t y p e 0 2 / 2 5 / 1 1
1 2 0 8 0 2 / 2 5 / 1 1
1 2 0 9 0 4 0 2 / D e f i n e c p y _ W e b S e r v i c e s _ D s 0 2 / 2 5 / 1 1
1 2 1 0 0 4 0 2 / c o p y Q r p g l e s r c , C B . P h o n e s 0 2 / 2 5 / 1 1
1 2 1 1 0 4 0 2 / U n d e f i n e c p y _ W e b S e r v i c e s _ D s 0 2 / 2 5 / 1 1
1 2 1 2 0 2 / 2 5 / 1 1
1 2 1 3 0 4 0 2 / D e f i n e c p y _ g e t P h o n e B y T y p e _ O u t p u t 0 2 / 2 5 / 1 1
1 2 1 4 0 4 0 2 / c o p y Q r p g l e s r c , C B . P h o n e s 0 2 / 2 5 / 1 1
1 2 1 5 0 4 0 2 / U n d e f i n e c p y _ g e t P h o n e B y T y p e _ O u t p u t 0 2 / 2 5 / 1 1
1 2 1 6 0 2 / 2 5 / 1 1
2 5 0 0 D p C o n t a c t I d S 1 0 S 0 I n z ( 0 ) M e m b e r # 0 3 / 1 8 / 1 0
2 6 0 0 0 3 / 0 1 / 1 0
2 7 0 0 / f r e e 1 2 / 0 8 / 0 9
2 8 0 0 0 1 / 0 8 / 1 0
3 8 0 0 0 3 / 1 8 / 1 0
3 8 0 1 # o = 0 ; 0 2 / 1 0 / 1 1
3 8 0 2 s e t l l * l o v a l m e m b e r ; 0 2 / 1 0 / 1 1
3 8 0 3 d o u % e o f ( m e m b e r ) ; 0 2 / 1 0 / 1 1
3 8 0 4 # o = # o + 1 ; 0 2 / 1 0 / 1 1
3 8 0 6 r e a d m e m b e r ; 0 2 / 2 5 / 1 1
3 8 0 7 i f n o t % e o f ; 0 2 / 2 5 / 1 1
3 8 0 8 0 0 M H M e m N u m = M e m b # ; 0 2 / 2 5 / 1 1
3 8 0 9 0 0 M H W r k E m a i l = G e t E m a i l ( M e m N u m ) ; 0 2 / 2 5 / 1 1
3 8 1 0 0 4 0 2 p P h o n e B y T y p e = G e t P h o n e B y T y p e ( M e m b # : ' H O M E ' ) ; 0 2 / 2 5 / 1 1
3 8 1 1 0 4 0 2 p P h o n e s 3 = % a d d r ( P h o n e s o u t 3 . C P h o n e s ) ; 0 2 / 2 5 / 1 1
3 8 1 2 0 4 0 2 p P h o n e s 4 = % a d d r ( P h o n e s O u t 3 . C P h o n e s 2 ) ; 0 2 / 2 5 / 1 1
3 8 1 3 0 4 0 2 p P h o n e B y T y p e = G e t P h o n e B y T y p e ( m e m b # : ' B U S N ' ) ; 0 2 / 2 5 / 1 1
3 8 1 4 0 4 0 2 p P h o n e s 3 = % a d d r ( P h o n e s o u t 3 . C P h o n e s ) ; 0 2 / 2 5 / 1 1
3 8 1 5 0 4 0 2 p P h o n e s 4 = % a d d r ( P h o n e s O u t 3 . C P h o n e s 2 ) ; 0 2 / 2 5 / 1 1
6 6 0 1 e n d i f ; 0 2 / 2 5 / 1 1
6 6 0 2 e n d d o ; 0 2 / 1 0 / 1 1
6 7 0 0 0 6 / 3 0 / 1 0
6 8 0 0 * i n L R = * o n ; 1 2 / 0 7 / 0 9
6 9 0 0 / e n d - f r e e 1 2 / 0 7 / 0 9
5 7 2 2 W D S V 5 R 4 M 0 0 6 0 2 1 0 S E U S O U R C E L I S T I N G 0 3 / 0 2 / 1 1 0 8 : 3 6 : 5 0 I I M I A D E V P A G E 2
S O U R C E F I L E . . . . . . . I I E R 0 0 V W / Q R P G M O D
M E M B E R . . . . . . . . . T S T P H O N E S
S E Q N B R * . . . + . . . 1 . . . + . . . 2 . . . + . . . 3 . . . + . . . 4 . . . + . . . 5 . . . + . . . 6 . . . + . . . 7 . . . + . . . 8 . . . + . . . 9 . . . + . . . 0
* * * * E N D O F S O U R C E * * * *
ÿþ 5 7 2 2 W D S V 5 R 4 M 0 0 6 0 2 1 0 S E U S O U R C E L I S T I N G 0 3 / 0 2 / 1 1 0 8 : 3 6 : 2 8 I I M I A D E V P A G E 1
S O U R C E F I L E . . . . . . . I I L I B / Q R P G L E S R C
M E M B E R . . . . . . . . . C B . P H O N E S
S E Q N B R * . . . + . . . 1 . . . + . . . 2 . . . + . . . 3 . . . + . . . 4 . . . + . . . 5 . . . + . . . 6 . . . + . . . 7 . . . + . . . 8 . . . + . . . 9 . . . + . . . 0
1 0 0 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * 1 2 / 0 7 / 0 9
2 0 0 * - * 1 2 / 0 7 / 0 9
3 0 0