× 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: QDMRTVFO API won't work - help
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Thu, 28 Dec 2000 17:12:19 -0600 (CST)


Hi Mark....

There are two problems with this code that jump out at me.  I'll explain
more below.

On Thu, 28 Dec 2000, Mark A. Manske wrote:

> D RTRNOVRDATA     S           1024A   INZ
> D LENGTH          S              9B 0 INZ(%SIZE(RTRNOVRDATA))
> D FORMATNAME      S              8A   INZ('OVRL0100')
> D FILENAME        S             10A   INZ('MWPCUSTHST')
> 
> DOVRL0100         DS
> D BYTESRETURNED                  9B 0
> D BYTESAVAILABLE                 9B 0
> D FILENAMEUSED                  10A
> D LIBRARYNAME                   10A
> D MEMBERNAME                    10A
> D FINALOVERRIDE                 10A
> 
> D ERRORCODE       DS
> D BYTPRV                         9B 0
> D BYTAVA                         9B 0
> D MSGID                          7A
> D ERROR#                         1A
> D MESSAGEDATA                  200A
> 
> C                   CALL      'QDMRTVFO'
> C                   PARM                    RTRNOVRDATA
> C                   PARM                    LENGTH
> C                   PARM                    FORMATNAME
> C                   PARM                    FILENAME
> C                   PARM                    ERRORCODE
> 

1)  Your ErrorCode DS isn't working because you didn't initialize the
    "bytes returned" value to the size of the error code structure.  

2)  Your OVRL0100 DS isn't working because there's no code to put data
    into that structure.  In other words, you aren't moving the data from 
    RTRNOVRDATA into OVRL0100.

Instead of using RTRNOVRDATA, why don't you just specify OVRL0100 as the
first parm on your CALL?   Of course, you'll have to change the LENGTH
parm to be the size of OVRL0100, as well...  this way you don't need to
move the results from RTRNOVRDATA to OVRL0100

Here is your code, updated with my suggestions.  I tested it, and it
works.  I had to truncate some of your variable names, since I'm at V3R2,
and I can't have names that long :(   I also used the name of one of my
own files, instead of the one you provided...

     D LENGTH          S              9B 0 INZ(%SIZE(OVRL0100))
     D FORMATNAME      S              8A   INZ('OVRL0100')
     D FILENAME        S             10A   INZ('ITMMAST')

     DOVRL0100         DS
     D BYTESRETUR                     9B 0
     D BYTESAVAIL                     9B 0
     D FILENAMEUS                    10A
     D LIBRARYNAM                    10A
     D MEMBERNAME                    10A
     D FINALOVERR                    10A

     D ERRORCODE       DS
     D BYTPRV                         9B 0 INZ(256)
     D BYTAVA                         9B 0 INZ(0)
     D MSGID                          7A
     D ERROR#                         1A
     D MESSAGEDAT                   200A

     C                   CALL      'QDMRTVFO'
     C                   PARM                    OVRL0100
     C                   PARM                    LENGTH
     C                   PARM                    FORMATNAME
     C                   PARM                    FILENAME
     C                   PARM                    ERRORCODE

     c                   eval      *inlr = *on


So... that code works.    There are a few things that I suggest, if you
want to improve your code.   

1)  Instead of using CALL, make a prototype and use CALLP.  It provides
     you with better syntax checking, and you can throw your prototypes
     into /COPY members so you can use them in many programs.

2)  Instead of using 9B 0 for the "BINARY(4)" variables, use 10I 0.  
     9B 0 puts some unnecessary limits on the size of the number that
     can be stored in it, and it also doesn't perform as well as 10I 0
     does.  Both are 4-byte numbers stored in binary format.

So here's the way that I always do it:

     D RtvFileOvr      PR                  ExtPgm('QDMRTVFO')
     D   RcvVar                   32766A   options(*varsize)
     d   RcvVarLen                   10I 0 const
     D   Format                       8A   const
     D   FileName                    10A   const
     D   ErrorCode                32766A   options(*varsize)

     D dsEC            DS
     D  dsECBytesP             1      4B 0 INZ(256)
     D  dsECBytesA             5      8B 0 INZ(0)
     D  dsECMsgID              9     15
     D  dsECReserv            16     16
     D  dsECMsgDta            17    256

     d dsOVRL0100      DS
     D   dsOvrBytRt                  10I 0
     D   dsOvrBytAv                  10I 0
     D   dsOvrFile                   10A
     D   dsOvrLib                    10A
     d   dsOvrMbr                    10A
     d   dsOvrFTyp                   10A

     D Msg             S             50A
     D peFileName      S             10A

     C     *entry        plist
     c                   parm                    peFileName

     c                   callp     RtvFileOvr(dsOVRL0100: %size(dsOVRL0100):
     c                               'OVRL0100': peFileName: dsEC)

     c                   if        dsECBytesA > 0
     c                   eval      Msg = 'Error ' + dsECMsgID + ' occurred'
     c                   dsply                   Msg
     c                   eval      *inlr = *on
     c                   return
     c                   endif

     c                   eval      Msg = 'Overridden to: ' +
     c                                 %trim(dsOvrLib) + '/' +
     c                                 %trim(dsOvrFile) + '(' +
     c                                 %trim(dsOvrMbr) + ')'

     c                   dsply                   Msg

     c                   eval      *inlr = *on


Hope that helps...



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