|
midrange.com
Thanks for the advice Scott.
I have got the following code to work.
This pointer stuff is pretty simple, I am embarrassed for asking.
I used a MODS to effectively allocate 16 * 64K memory and
I got the API to pass back 1M (approx) of data max.
I then got the addr of the MODS and used based DS to get
the info I want, namely the Receiver names.
I understand I can 'fine tune' the actual size to pass to
the API but as I got a 16 occur DS I dont think its needed.
If the code below has flaws I would appreciate comments
as I am still a bit afraid of pointers, I know its possible to
crash stuff (OS maybe) if pointers go awry.
Thanks
Frank Kolmann
H DFTACTGRP(*NO) ACTGRP(*CALLER) OPTIMIZE(*NONE)
D RtvJrnInf PR ExtProc( 'QjoRetrieveJournal+
D Information' )
D RjRcvrVar 1 Const
D Options( *VarSize )
D RjLenRcvrVar 10I 0 Const
D RjQlJrnName 20 Const
D RjFmtName 8 Const
D RjJrnInf 1 Const
D Options( *VarSize )
D RjApiErr Like( ApiErr )
D ApiErr DS
D AeBytesProv 10U 0
D AeBytesRetd 10U 0
D AeMsgId 7
D 1
D AeMsgDta 256
* This DS is initialised to request that we want ALL the
* receivers associated with the journal
* VD Key = 1 means Journal Receiver Directory Information
*JrnInfToRtv DS
* JtrNumVarLenR This is 1 as I am only sending(asking) for 1 set of
info
* VDLen The length of this request is 16 bytes (not incl
JtrNumVarLenR)
* VDKey I am asking for the reveivers (code is 1)
* VDLenDta This req passes no data but a min of 4 bytes must be
specified
* VDDta This is the 4 empty bytes
D JrnInfToRtv DS
D JtrNumVarLenR 10I 0 Inz(1)
D VDLen 10U 0 Inz(16)
D VDKey 10U 0 Inz(1)
D VDLenDta 10U 0 Inz(4)
D VDDta 4
D PrmJrnName S 10
D PrmJrnLib S 10
D DtaStr S 10U 0
D KeyDtaPos S 10U 0
D RcvDtaPos S 10U 0
D I S 10U 0
D J S 10U 0
D Psize S 10U 0 Inz(1048560)
D PS S *
D P1 S *
D P2 S *
D P3 S *
D RJRN0100 DS 65535 OCCURS(16)
D RjBytesRetd 10I 0
D RjBytesAvl 10I 0
D RjKeyOffs 10I 0
D RjJnlNam 10
D RjJnlLib 10
D RjAttachRcvrN 201 210
D RjAttachRcvrL 211 220
D Rfill1 448 448
D RjKeys 10U 0
***** Use offsets to get to the receiver info
D ApiKeys DS based(P1)
D RjKey 10U 0
D RjKeyOff 10U 0
D RjKeyHdrLen 10U 0
D RjKeyNumEnt 10U 0
D RjKeyEntLen 10U 0
***** KEY 1 (Jnl Receiver data)
D RcvInf DS based(P2)
D RjTotRcv 10U 0
D RjTotRcvSiz 10U 0
D RjTotSizMult 10U 0
D RjResrv1 8
D RcvInfDS DS based(P3)
D RjRcvNam 10
D RjRcvLib 10
D RjRcvNbr 5
D RjRcvAttDte 13
D RjRcvSts 1
D RjRcvSavDte 13
D RjRcvLclSys 8
D RjRcvSrcSys 8
D RjRcvSiz 10U 0
D RjResrv2 56
C *Entry Plist
C Parm PrmJrnName
C Parm PrmJrnLib
/Free
*INLR = *On;
// Initialize bytes provided in two data structures
AeBytesProv = %Size( ApiErr );
RjBytesAvl = Psize;
// Invoke the QjoRetrieveJournal API
CallP RtvJrnInf( RJRN0100:
Psize:
PrmJrnName + PrmJrnLib:
'RJRN0100':
JrnInfToRtv:
ApiErr );
// Following the above CallP, if AeBytesRetd = *Zero, then
// RjAttachedRcvrName contains the attached receiver name and
// RjAttachedRcvrLib contains the attached receiver library name
RjAttachRcvrN = RjAttachRcvrN;
RjAttachRcvrL = RjAttachRcvrL;
DtaStr = RjKeyOffs + 4; //Key data actually starts from
RjKeys on
PS = %Addr(RJRN0100);
P1 = PS + DtaStr - 20;
for j = 1 to RjKeys;
P1 = P1 + 20;
If RjKey = 1; // Process Receiver Info
// Now we are going to get all the receiver names
ExSR GetRcvNam;
EndIf;
endfor;
BegSR GetRcvNam;
P2 = PS + DtaStr + RjKeyOff ;
P3 = PS + DtaStr + RjKeyOff + RjKeyHdrLen-
RjKeyEntLen;
for j = 1 to RjKeyNumEnt;
P3 = P3 + RjKeyEntLen;
// Here we have the name of each Receiver in turn in RjRcvNam
RjRcvNam = RjRcvNam;
endfor;
EndSR;
/end-free
>
>from: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
>subject: Re: Journal Receiver Example. Help needed.
>> I have used code posted recently that showed how to get the name of the
>> attached journal receiver,
>
>Hmmm... some of the coding style looks like Carsten Flensburg (I read a
>lot of his code for some reason) other parts of it don't look familiar --
>I assume that that's your part of it.
>
>[SNIP]
>> In the archives I note Carsten Flensburg and others mention pointer
>> handles.
>
>Not sure what you mean by "handles" but yes, a little bit of pointer logic
>would certainly solve your problem.
>
>> Can I use pointers to get back more than 64K bytes of data in case I
have
>> more than 512 associated receivers.
>
>Well, a pointer just points to an address in RAM, it does not infer any
>length by itself. You can ask the system to allocate memory for you in a
>few different ways... The most basic way is to use the %ALLOC() BIF (or
>ALLOC op-code) to grab a chunk of memory from the heap -- which is limited
>to about 16mb of data. Much more than 64k!
>
>Other methods would be to get a pointer to a user space, which would give
>you a 16mb area that could be configured to automatically expand as
>needed.
>
>Or to use teraspace, which would give you the ability to address gigabytes
>of memory at once -- if you really need to go that high ;)
>
>> Can I get the API to populate a User Space or a MODS.
>> I have used User Spaces previously but those APIs directly populated.
>> I have searched the archives but I am too thick to get it, any help is
>> muchly appreciated.
>
>It's too late and I'm too tired to code a complete example of this.
>Try taking the following steps:
>
> 1) Call the API with a very small data structure that contains only
> two fields, the "bytes provided" and "bytes available" fields.
> The API will put the number of bytes of memory that it needs
> into the "bytes available" field -- you can use this to create
> a data area or memory allocation of the appropriate size.
>
> 2) Create a user space, or allocate memory. In either case, you'll
> want to get a pointer to that memory.
>
> 3) Base a variable on the pointer from step 2.
>
> 4) Call the API again, this time pass the variable from step 3 as
> the receiver variable to the API. The API will load up the memory
> that the variable is in -- and since the variable is based on the
> pointer, that area of memory will be the area that the user space
> or ALLOC-ed memory resides in.
>
> 5) Access the memory as needed with a pointer.
>
> 6) When you're done, either deallocate the memory with the DEALLOC
> op-code or delete the user space.
>
>Hope that helps...
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
