× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Yes, the example is just to demonstrate the danger of using *prv. This
is especially true for software vendor. Since software vendor has no
way to make sure customers recompile all their programs that uses the
service program. The only way for vendor to guarantee code not get
wrongly execute is to not include the *prv.

The example just assumes that developer miss an existing program that
uses IFS_Proc2. The program will still run without getting signature
violation.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Murphy, Mark
Sent: Thursday, February 14, 2008 1:45 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Processes after CRTSRVPGM

As Scott said, you can't remove a procedure from a service program
safely without invalidating the entire signature, whether you are using
*PRV or not.

I still don't understand why you would want to remove a procedure from a
service program while it was still being used by some programs.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Lim Hock-Chai
Sent: Thursday, February 14, 2008 2:32 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Processes after CRTSRVPGM

Not sure I understand your question. My example is merely to show the
danger of using *prv. In this example, I just try to demonstrate that
if developer forgot to recompile an existing program that was compiled
before the *current was added, this program will not get signature
violation. At run time it will actually execute IFS_Proc3 even though
the statement is coded to execute IFS_Proc2. This is where I don't
think *prv should be used (Again personal preference only). It does not
give you any protection and actually given developer some false sense of
security.





-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Murphy, Mark
Sent: Thursday, February 14, 2008 1:13 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Processes after CRTSRVPGM

Explain to me why I would expect any program to be able to call a
procedure that I have removed from the service program. If you use a
tool incorrectly you are bound to have trouble.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Lim Hock-Chai
Sent: Thursday, February 14, 2008 10:51 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Processes after CRTSRVPGM

If you binding language looks like below, guess what will happen if you
forgot/miss recompile an existing program that is still using one of the
*prv signature? This existing program will not get signature violation.
It just going to execute the wrong procedure when executing IFS_Proc2.

STRPGMEXP PGMLVL(*CURRENT)
EXPORT SYMBOL(IFS_Proc1)
EXPORT SYMBOL(IFS_Proc3)
ENDPGMEXP

STRPGMEXP PGMLVL(*PRV)
EXPORT SYMBOL(IFS_Proc1)
EXPORT SYMBOL(IFS_Proc2)
EXPORT SYMBOL(IFS_Proc3)
ENDPGMEXP

STRPGMEXP PGMLVL(*PRV)
EXPORT SYMBOL(IFS_Proc1)
EXPORT SYMBOL(IFS_Proc2)
ENDPGMEXP


STRPGMEXP PGMLVL(*PRV)
EXPORT SYMBOL(IFS_Proc1)
ENDPGMEXP




-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck
Sent: Thursday, February 14, 2008 9:43 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Processes after CRTSRVPGM

Lim Hock-Chai wrote:

My personal preference is never use *prv. IMHO, it is quite
dangerous.

Can you write a little more on why you feel *PRV is dangerous? I've
used this exclusively since V3 and haven't encountered any problems...
I'm hoping I haven't missed something!
--buck
--
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) 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 e-mail transmission contains information that is intended to be
confidential and privileged. If you receive this e-mail and you are not
a named addressee you are hereby notified that you are not authorized to
read, print, retain, copy or disseminate this communication without the
consent of the sender and that doing so is prohibited and may be
unlawful. Please reply to the message immediately by informing the
sender that the message was misdirected. After replying, please delete
and otherwise erase it and any attachments from your computer system.
Your assistance in correcting this error is appreciated.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.