× 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: QYASPOL API not returning receiver data
  • From: Dan Rasch <drasch@xxxxxxxxxxxx>
  • Date: Thu, 17 May 2001 08:58:53 -0500 (CDT)


I THINK I AM GETTING SOMEWHERE WITH THIS API, BUT, WELL.....

 Rob Dekko was helping me with a CL to grab system ASP numbers using
 the QYASPOL API, but all I got was the error message:
 
 GUI0141 'Filter specification is not valid'.
 
 
 Then Bruce Vining responded with:

 Try LEN(16) for &FLTR.  Note that this will still not get you receiver
 data as &NUMR is 0, but it will get you past the GUI0141.

 Bruce

 So I changed &NUMR to 1, but still no receiver data.

 The web page at publib.boulder.ibm.com ...qyaspol.htm
 states this:

 The number of records in the list to put into the receiver variable
 after filtering has been done.
 -1  All records are built synchronously in the list by the main job
  0  All records are built asynchronously in the list by the server job
  records to return
     If a positive number of records is specified, at least that many
     records are built asynchronously and the remainder are built 
     asynchronously by a server job



> Heres the code:
> 
>              PGM                                                       
>              DCL     VAR(&RCVR)    TYPE(*CHAR) LEN(113)                
>              DCL     VAR(&LEN)     TYPE(*CHAR) LEN(4)                  
>              DCL     VAR(&LIST)    TYPE(*CHAR) LEN(80)                 
>              DCL     VAR(&NUMR)    TYPE(*CHAR) LEN(4)                  
>              DCL     VAR(&NUMF)    TYPE(*CHAR) LEN(4)                  
>              DCL     VAR(&FLTR)    TYPE(*CHAR) LEN(14)                 
>              DCL     VAR(&FMT)     TYPE(*CHAR) LEN(8) VALUE('YASP0200')
>              DCL     VAR(&ERR)     TYPE(*CHAR) LEN(80)                 
>              DCL     VAR(&FSIZE)   TYPE(*CHAR) LEN(4)                  
>              DCL     VAR(&FKEY)    TYPE(*CHAR) LEN(4)                  
>              DCL     VAR(&FFDSIZE) TYPE(*CHAR) LEN(4)                  
>              DCL     VAR(&FDATA)   TYPE(*CHAR) LEN(4)                  
>              CHGVAR  VAR(%BIN(&FSIZE 1 4))     VALUE(16)             
>              CHGVAR  VAR(%BIN(&FKEY 1 4))      VALUE(1)              
>              CHGVAR  VAR(%BIN(&FFDSIZE 1 4))   VALUE(4)              
>              CHGVAR  VAR(%BIN(&FDATA 1 4))     VALUE(-1)             
>              CHGVAR  VAR(&FLTR)                VALUE(&FSIZE   *CAT + 
>                                                      &FKEY    *CAT + 
>                                                      &FFDSIZE *CAT + 
>                                                      &FDATA)         
>                                                                      
>              CHGVAR   VAR(%BIN(&ERR 1 4))      VALUE(80)             
>              CHGVAR   VAR(%BIN(&ERR 5 4))      VALUE(0)              
>              CHGVAR   VAR(%SST(&ERR 9 72))     VALUE(' ')            
>              CHGVAR   VAR(%BIN(&LEN 1 4))      VALUE(113)            
>              CHGVAR   VAR(%BIN(&NUMF 1 4))     VALUE(1)              
>              CHGVAR   VAR(%BIN(&NUMR 1 4))     VALUE(1)              
>              CALL     PGM(QGY/QYASPOL) + 
>                         PARM(&RCVR     + 
>                              &LEN      + 
>                              &LIST     + 
>                              &NUMR     + 
>                              &NUMF     + 
>                              &FLTR     + 
>                              &FMT      + 
>                              &ERR)       
>              ENDPGM           
> 
> 
> It seems to not like the value in &FLTR.
> I looked up the API at publib.boulder.ibm.com , but .....
> 
> the harder I think, the confuser I get
> 
>                                                                 
> Dan Rasch - because if the human species concentrated on the really 
> important things in life, there would be a shortage of fishing poles!
> 
> 
> +---
> | 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
> +---
> 

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

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.