× 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: API parameter lengths
  • From: "Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>
  • Date: Sat, 07 Jul 01 11:15:20 +1000

"
Hello Gene,

You wrote:
>Here's a case where the command line fails to pad blanks to 32 bytes.  I
>call the QSYRGFN API on V4R4 like this from the command line to register a
>30-character function named XYZ:

The QSYRGFN program looks like a C program.  That changes the rules.  See 
the excerpt below from the CL Programming Guide.

>This creates a function named 'XYZ' + X'00' + 26 blanks.  Huh?  Why did 
>the command line insert a trailing null after 'Z'?  Is this a feature?  

The CALL command is looking at the target program and NULL terminates the 
string because that is probably what a C program expects.  The assumption is 
wrong in this case because QSYRGFN has no length value associated with the 
Function ID and since the documentation does not state a NULL terminator is 
required the API expects 30 characters padded with blanks.  You can also 
infer this from the function prototype in qsyrgfn.h and qsyrgfn1.h which 
define the first parameter as char[30] rather than a pointer to a null 
terminated string.

>Now I call the QSYRGFN API like this from the command line and explicitly 
>pad the first parameter to 32 blanks:
>This creates a function named 'XYZ' + 27 blanks, as I expected.  

You'll probably find that the 33rd byte is a NULL character in which case 
CALL is behaving consistently.

>Somehow
>the QSYRGFN API can determine whether the command line caller typed a
>3-character string or a 32-character string in parameter one.  Can an MI
>program determine this information, too?

Here is the relevant passage from the CL Programming Guide.

 An exception to the previous description is when the CALL command calls an
 ILE C/400 program. When using the CALL command to call a C/400 program and
 pass character or logical constants, the system adds a null character
 (x'00') after the last non-blank character. If the constant is a character
 string that is enclosed in apostrophes or a hexadecimal constant, the null
 character is added after the last character that was specified. This
 preserves the trailing blanks (x '40' characters). Numeric values are not
 null-terminated. See the IBM SAA C/400 User's Guide, SC09-1347 for more
 information.

Regards,
Simon Coulter.


 FlyByNight Software         AS/400 Technical Specialists       
 Eclipse the competition - run your business on an IBM AS/400.  
                                                                
 Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\   
 Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /   
                                                           X    
               ASCII Ribbon campaign against HTML E-Mail  / \   

+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.