|
midrange.com
When you say a *MODULE, I hope you are not using *ENTRY points to create
service programs instead of writing service programs with procedures. The whole
concept just makes me reek.
In any case, any service program can be dynamically loaded. When you bind a
service program to a program, you are hard coding the name of the service
program and giving IBM control of when the service program loads. At program
startup, IBM calls system API's and loads the service program. They get a
pointer to each procedure that is going to be used. All of the occurs under the
covers and you cannot see it.
But what happens if you do not know which service program to call until you are
running the program? The solution is to load the service program dynamically.
You call system API's to load the service program and get pointers to the
procedures. From that point on, everything is the same just as if IBM had
loaded the service programs.
I have service programs that do just that and example programs showing how to
make the calls. With the logic encapsulated in a service program, very easy to
do. (Again, thanks to David Morris for publishing the original code).
I have sent this code to others in the past. If you are interested, let me
know.
Here is example. Note the declaration for GetInputAmt. The declaration of the
external procedure is based on a procedure pointer instead of a name. This is
one of the tricks to dynamically loading a service program. Let me know if
there are any questions.
/copy *libl/qsrcf,cb_Std_Con
/copy *libl/qsrcf,cb_StdType
/copy *libl/qsrcf,XVDYNL_PR
* Prototype for function GetInputAmt based on a procedure pointer.
* Must have a procedure pointer and prototype for each procedure you
* want to call dynamically.
* This procedure receives an account number and returns a 7/2 amount.
d pptrGetInputAmt...
d s Like(StdPrcPtr)
d GetInputAmt...
d pr 7p 2 ExtProc(pptrGetInputAmt)
d
d PR_InAccountNumber...
d 5p 0 Value
d ActivationMark01...
d s Like(StdActMark)
d ActivationMark02...
d s Like(StdActMark)
d InputAmt...
d s 7p 2
d pptr01...
d s Like(StdPrcPtr)
d pptr02...
d s Like(StdPrcPtr)
/Free
// Activate the first service program.
ActivationMark01 = DYNL_ActivateServiceProgram('TEST_EF01':
'*LIBL' );
// Now get a procedure pointer to procedure we are going to use.
pptr01 = DYNL_GetPointerToExportedProcedure(ActivationMark01:
'GetInputAmt' );
// Now activate the second program.
ActivationMark02 = DYNL_ActivateServiceProgram('TEST_EF02':
'*LIBL' );
// Now get a procedure pointer to procedure we are going to use.
pptr02 = DYNL_GetPointerToExportedProcedure(ActivationMark02:
'GetInputAmt' );
// Call the procedure in the first service program.
pptrGetInputAmt = pptr01;
InputAmt = GetInputAmt(1005);
// Now call same procedure in second service program.
pptrGetInputAmt = pptr02;
InputAmt = GetInputAmt(1005);
// Note that the amount returned is different from each service
program. You could call any number
// of different service programs with same prototypes as long as each
procedure
// has the same prototype. You can, also, have different named
procedure in each service program as
// long as they have the same interface.
*InLR = *On;
Return;
/End-Free
-----Original Message-----
From: PAPWORTH Paul [mailto:Paul.Papworth@xxxxxxx]
Sent: Tuesday, May 24, 2005 12:29 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Variable Modules
We are getting more and more into ILE RPG programming , and I recently came
across the following problem. Is it possible to have a variable that contains
the *module to be called ? , like we did for years with dynamic program
calls. I have seen some suggestions which use the PROCPTR feature but this has
been less than clear.
Thanks in anticipation
-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la
part de rpg400-l-request@xxxxxxxxxxxx
Envoyé : vendredi 20 mai 2005 19:01
À : rpg400-l@xxxxxxxxxxxx
Objet : RPG400-L Digest, Vol 4, Issue 555
Send RPG400-L mailing list submissions to
rpg400-l@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/rpg400-l
or, via email, send a message with subject or body 'help' to
rpg400-l-request@xxxxxxxxxxxx
You can reach the person managing the list at
rpg400-l-owner@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of RPG400-L digest..."
Today's Topics:
1. RE: work files in qtemp (Larry Ducie)
2. RE: File object got deleted!
(Chaudhary, Sachin (GE Equipment Services, Consultant))
----------------------------------------------------------------------
message: 1
date: Fri, 20 May 2005 17:33:32 +0100
from: "Larry Ducie" <larry_ducie@xxxxxxxxxxx>
subject: RE: work files in qtemp
Hi Ken,
<snip>
If Larry and I worked at the same company, and he used his utility to take
over one of my jobs and had it delete an object, then *I* deleted the
object. If object auditing is turned on and you looked the audit record for
the deletion, it would show deleted by me. There would be no clue that Larry
was the one who instigated it, except the program name might show the name
of his exit program, but even then there would be no way to know from that
audit record who it was that actually used the utility.
</snip>
...and the deletion of the object caused the application to crash, and the
company lost $millions? Would you still insist that "you" deleted the
object? :-)
I agree with you about the way it works, I wont argue that point - on a
system level it's the user running the job that performs the action. Or
rather, the action is performed under the user profile that runs the job.
I've never argued otherwise. The problem here, as you pointed out, is that
the audit trail is broken - that's the big security concern for me. You'd
have to prove it "wasn't" you that deleted the object when all evidence
indicates that you did.
Having said all that, it's been a really useful tool for me over the years
(whichever way it works). It can still bel useful, even if it's only used as
a development tool - to help debugging batch jobs.
This is quite a good topic. Makes you think.
Have a good weekend.
Cheers
Larry Ducie
------------------------------
message: 2
date: Fri, 20 May 2005 12:45:40 -0400
from: "Chaudhary, Sachin \(GE Equipment Services, Consultant\)"
<sachin.chaudhary@xxxxxx>
subject: RE: File object got deleted!
I got it. Thanks a lot.
-----Original Message-----
From: rpg400-l-bounces+sachin.chaudhary=ge.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+sachin.chaudhary=ge.com@xxxxxxxxxxxx]On Behalf
Of Scott Klement
Sent: Friday, May 20, 2005 3:18 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: File object got deleted!
> 1. Thinking that creating a new file from DDS will lead to recompiling
> all programs to avoid level check error
[SNIP]
> Creating a duplicate object, to production didn't change the
> Identifier??
[SNIP]
> Can you explain me?
What does a record format level check do, and why do we need it?
First, understand the problem that it's designed to solve:
When you compile an RPG program that uses an external definition, what it
does is look at the fields in the file and generate I-specs (yes, the old
fashioned input specs) in your program for you.
Since these are now compiled into your program, if you change anything in
the record format, it would read from the wrong positions.
For example, consider the following file:
A R TESTFMT
A FIELD1 10A
A FIELD2 10A
When you compile an RPG program that uses this file, and use an external
definition, the system will AUTOMATICALLY create the following input
specs...
ITESTFMT NS
I 1 10 field1
I 11 20 field2
If you go back and change the file so tha FIELD1 is 15A instead of 10,
you now have the following:
A R TESTFMT
A FIELD1 15A
A FIELD2 10A
Now FIELD1 is taking up positions 1-15 and field2 is 16-25. However,
unless you re-compile your RPG program, it won't know that! Instead,
it'll continue to try to read field1 from positions 1-10, and FIELD2 from
11-20. That means that FIELD2 in the RPG program will actually read data
out of FIELD1!
So, IBM insituted record format level identifiers. The system computes a
"checksum" or "hash" of the things that are important to the format of a
record. These things are the field's name, length, data type, and
position in the record.
So, in the above example, the record format level identifier would have
changed, since the size of FIELD1 has changed, and also because the
position of FIELD2 has changed.
When you compile your RPG program, it reads the external definition and
generates the input specs as I explained above. It saves the record
format level from the file into the RPG program's compiled object. Every
time it tries to open that file, it compares the one it saved with the one
in the file. If they don't match, it knows it's input specs are wrong, and
aborts the program. This way, a programmer won't forget to recompile his
program to generate the correct input specs.
Now that you understand that, why didn't CRTDUPOBJ or re-building the PF
from source cause the record format level id to be different? Quite
simply because the record format was the same. Since it was the same, the
system generates the same checksum. The input specs that it would
generate are identical, so there's no reason for the level id to be
different.
Make sense?
> 2. How can we know from which AS400 id was this object deleted?. History
> log (DSPLOG QHST) is no good.
The history log isn't intended for that sort of thing. If you want the
system to log who deleted files, you need to turn on object auditing.
Unfortunately, if the file is already gone, it's too late. You need to
turn it on ahead of time so that these sort of events are logged.
Do a search for CHGOBJAUD and CHGUSRAUD and you should find more info on
object auditing.
good luck
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
------------------------------
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) digest list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
End of RPG400-L Digest, Vol 4, Issue 555
****************************************
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.
