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


  • Subject: Re: Procedure changing not passed values
  • From: "Marcin Sagan" <marcin_sagan@xxxxx>
  • Date: Thu, 12 Jul 2001 12:19:47 +0200

Barbara
This example was for testing purpose only and not intended to use in
porductoin or wherever of course :) Just to see what happen when parameters
are passed in diferent ways to procedure. But If I Understood You correctly
I can corrupt databases only by runing this small "illegal" program? Even
when I do not use/open any files in it?


Regards
Marcin

----- Original Message -----
From: <bmorris@ca.ibm.com>
To: <RPG400-L@midrange.com>
Sent: Tuesday, July 10, 2001 10:56 PM
Subject: Re: Procedure changing not passed values


>
> >Date: Tue, 10 Jul 2001 12:00:31 +0200
> >From: "Marcin Sagan" <marcin_sagan@wp.pl>
> >
> >why when I call ProcA (code below) without parameters it gives me
> >"MCH3601-Pointer not set for location referenced." (what I am expected)
> but
> >when first call is with parms and second without  ProcA change values of
> >this (not passed!) parameters anyway?
> > ...
> >p ProcA           b
> >d ProcA           pi
> >d  Par1                          2a   Options( *NoPass : *Omit )
> >d  Par2                          2a   Options( *NoPass : *Omit )
> >d  Par2                          2a   Options( *NoPass : *Omit )
> >d  Par3                          2a   Options( *NoPass : *Omit )
> >
> >  ... snip correct parameter-checking code
> >
> >  * What if we try to reach parms without checking?
> >c                   Eval      Par1 = 'AA'
>
> Marcin, when you make your first call, the parameters (pointers)
> get put on the "parameter stack".  The stack is not cleared when the
> call returns, so those pointers are still there for the second call.
>
> In your case, the values that got changed were "your" variables; in
> other cases of changing unpassed parameters, they could be anything.
>
> You shouldn't experiment with such illegal things.  You can't
> guess what is on the parameter stack even in a simple case like
> yours.  You could cause many bad things to happen:
>   - corrupting the data in your database
>   - crashing your program
>   - messing up the operating system, requiring a reinstall
>
> Barbara Morris
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---
>


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

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.