× 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: API's & upper vs. lower case
  • From: bvining@xxxxxxxxxxxx
  • Date: Wed, 30 Sep 98 11:35:32 CDT

Dave,

System APIs do not, in general, fold lowercase character data to
uppercase.  The APIs typically use exactly what was passed into them.
This is documented in the System API Programming manual under API
parameters (as it relates to object names anyway).

Command Analyzer, on the other hand, does fold lowercase to uppercase
unless double quotes are used in the string.  I suspect that QCMDEXC
is doing the uppercasing but this is somewhat a moot point as for sure
Command Analyzer (when processing the CRTDTAQ string value) will; and
so you end up with 'Plates' becoming 'PLATES' on the Create and 'Plates'
being used on the other APIs.

There is nothing you can do to control this in your function prototypes.
CONST suggests the API won't modify your local input argument, but
doesn't stop the API from modifying its local copy of your input
argument...

I believe what you need to do is make sure that the arguments are
consistently in uppercase.

Bruce

>
>Hi,
>I am using prototypes that serve as wrapper functions to call
>QCMDEXC, QUSROBJD, QSNDDTAQ and QRCVDTAQ  in an
>application that utilizes data queues.  The name of the data queue
>that I am using is "PLATES".  Well, on a number of occasions,
>I have mistyped  "PLATES", and instead types "Plates".
>
>Well it seems that when I check for the existence of the object
>using QUSROBJD, and "PLATES" already exists, but I specify
>"Plates"  instead, I get CPF9801 = obj not found.
>So I go and create the DTAQ "Plates" using QCMDEXC and CRTDTAQ,
>and that blows up because "PLATES" already exists.
>Well if it already exists, then why wasn't it found on the QUSROBJD call?
>When I fix my typing errors, its works as expected.
>
>I've encountered similar errors when I use "Plates" on the
>QSNDDTAQ rather then "PLATES".   I am told then that the
>DTAQ doesn't exist.
>
>FYI: My prototypes use the CONST keyword whenever passing
>       the DTAQ name.
>
>The problem is (obviously) easy enough to fix, but, how come
>this sort of behavior exists?  Does OS/400 know the difference between
>the DTAQs "PLATES" and "Plates"?  Is it the API's making the
>distinction?  Something with my prototypes?
>
>I appreciate any clarity that you can offer.
>TIA,
>Dave
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-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 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.