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



How could it know?  When RPG performs the call, it passes the specified
parameters as space pointers to the first byte of the value - this is called
"call by reference".  Until ILE, universal program calls did not include any
meta-information about the parameter.  When the System/38 shipped, we all
thought that universal inter-program calls were a miracle.  Prior to that,
programs written in RPG couldn't call a program written in COBOL or PL/I or
C or anything else.  On the 36, programs couldn't call each other at all.

I think that ILE includes the concept of a self-describing parameter.  That
is a parameter that contains its length, type, and attributes in a place
where all languages can find them.  Loading these independent descriptors
takes machine cycles that many of us aren't willing to pay.  So, if I call
your program with the right number of parameters but without the
descriptors, your program doesn't know what it is getting.  I don't want
that to change because I want high-performance calls.

I assume (that means that I don't know and I didn't look it up) that you
could reject calls from programs without descriptors.  That would allow you
to protect yourself from doing something wrong but it forces all the caller
programs who want to use your program to pay a price.

I think what you want is called "SMOP".  This is an acronym for "small
matter of programming".  In other words, you can have anything you want if
you or someone else sits down and writes the programs to make it happen.
The acronym is also a joke.  By saying "small matter ...", it implies that
it isn't much programming and there is little design or consequences from
it.  Sometimes the amount of programming isn't small and it requires a lot
of design time and the consequences are huge.  But that is why it is funny.

The 400 doesn't handle the problem and it won't be free for anyone to do it
and the consequences could be large.

Richard Jackson
mailto:richardjackson@richardjackson.net
www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Silvio Santos
Sent: Wednesday, July 12, 2000 10:20 AM
To: RPG400-L@midrange.com
Subject: RE: RPG/400 pgm strange behaviour




I understood more or less your explanation.
Shouldnt the AS/400 pass the pointers in a way to avoid those problems ?
Because if the lenghts of the variables are correct either in the calller as
in
the called it should work ok.
Silvio.






"Richard Jackson" <richardjackson@richardjackson.net> on 07/12/2000 04:03:14
PM

Please respond to RPG400-L@midrange.com

To:   RPG400-L@midrange.com
cc:    (bcc: Silvio Santos/VC/PT/BRAIN)

Subject:  RE: RPG/400 pgm strange behaviour




In this case, the parm lengths and definition location in the caller program
is the problem.  In the RPG program static storage allocation, the MSDT$E
field is defined as some length like 33 in the caller program, field $RTC$E
is defined immediately after it with a length of at least 6.

When this routine is called, the caller passes a space pointer to MSDT$E at
some address and the caller also passes a space pointer to field $RTC$E.
For this explanation, assume that the location of MSDT$E is decimal 1001 and
the location of $RTC$E is decimal 1034.

Neither field MSDT$E nor field $RTC$E occupies space in the callee program,
they are used by reference.  Since it is defined as a *ENTRY parameter, the
callee length should match the caller length definition.  When they don't
match, this is the AS/400 version of a memory leak - you can change memory
that doesn't belong to you.  I have spent days trying to find these things.

I am feeling like this is a very weak explanation of the problem.  If you
can't figure it out from this poor explanation, please drop me another note.

Richard Jackson
mailto:richardjackson@richardjackson.net
www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Silvio Santos
Sent: Wednesday, July 12, 2000 5:01 AM
To: RPG400-L@midrange.com
Subject: RPG/400 pgm strange behaviour




I have a program (RPG/400) that checks if some record exists and return.

These two filds are *ENTRY parms of the PGM:
MSDT$E - length 256
$RTC$E (*FOUND or *ERROR) - length 8A


The condition used is like this:

*IN,96    IFEQ '0'
          MOVEL'*FOUND'  $RTC$E
          MOVELMSDTOH  MSDT$E
          ELSE
          MOVEL'*ERROR'  $RTC$E
          ENDIF

It works fine, excepts for one thing: if the condition is true, when it
moves
the MSDTOH content to MSDT$E, it erases the $RTC$E field. For the other
hand,
when the first move is done, the '*Found' is placed in the 34th position of
the
field MSDT$E.

Is there any restriction about entry parms lenght ?
How can I resolve this?

Thanks
                     ,,,,,,
                   (o o)
-----------------------oOO--(_)--OOo------------------------
Silvio Santos                                BRAIN Portugal
Tel:    +351 252 248-120             Av. Joao Canavarro, 305
Fax:    +351 252 248-111            4480-668 Vila do Conde
                                                          Portugal
Email: silvio.santos@brainag.com
Web-Page: www.brainag.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
+---

+---
| 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
+---

                     ,,,,,,
                   (o o)
-----------------------oOO--(_)--OOo------------------------
Silvio Santos                                BRAIN Portugal
Tel:    +351 252 248-120             Av. Joao Canavarro, 305
Fax:    +351 252 248-111            4480-668 Vila do Conde
                                                          Portugal
Email: silvio.santos@brainag.com
Web-Page: www.brainag.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
+---

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

Follow-Ups:
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.