RE: Input inhibited

["Craig Jacobsen" <CraigJacobsen@xxxxxxxxxxx>]

The invite keyword is at the top, so it pertains to all record formats.

A barcode (auto enter) is scanned in the subfile control record that gathers
all the information for the display.

In the RPG, a write is done to display formats (prior to scan)
Write Sflcmd (function keys)
Write Sflhdr  (subfile control)

And then a read is done by the dspf:
Read PackProc (the entire display file).

The program is very large so it's hard to cut and paste but I think the
general info above should help.

TIA,

Craig




-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jerry Adams
Sent: Friday, June 01, 2007 12:29 PM
To: Midrange Systems Technical Discussion
Subject: Re: Input inhibited

Can you post snippets of the RPG code that gets the request and of the 
subfile control record with the keywords?


I never use the INVITE keyword and never have this kind of problem (just 
the usual insanity) with subfiles.  So the statement "no input is 
accepted to kick off the subfile build" sounds like something else is 
going on here.



        * Jerry C. Adams
*IBM System i5/iSeries Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
        615.995.7024
fax
        615.995.1201
email
        jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



Craig Jacobsen wrote:
> I just tried that, and now no input is accepted to kick off the subfile
> build.
>
> Craig
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeff Young
> Sent: Friday, June 01, 2007 10:40 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: Input inhibited
>
> Craig,
> I recently ran into a similar problem, and it had nothing to do with the
> type of workstation.
> Look in your display file for the INVITE keyword.  This was used way back
in
> the past for multiple requester terminal (MRT) programs.  It allows the
> program to continue after issuing a read operation without actualy waiting
> for data.
> Unless your program is actualy specifing the device that it is
communicating
> with, try removing the keyword and see if that fixes your problem.
>  
> Jeff Young 
> Sr. Programmer Analyst
> IBM -e(logo) server Certified Systems Exper - iSeries Technical Solutions
> V5R2 
> IBM  Certified Specialist- e(logo) server i5Series Technical Solutions
> Designer V5R3
> IBM  Certified Specialist- e(logo)server i5Series Technical Solutions
> Implementer V5R3 
>
>
>   
>  
>
>
>
>
>
> ----- Original Message ----
> From: Craig Jacobsen <CraigJacobsen@xxxxxxxxxxx>
> To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Sent: Friday, June 1, 2007 9:04:02 AM
> Subject: Input inhibited
>
>
> I am working on an old workstation program where the input inhibited light
> does NOT come on after a read while it builds the subfile.  This allows
the
> user to hit enter and the program bombs out with I/O error CPF4737 (output
> file not done).  If enter is not hit, the subfile displays properly.
>
> Is there a keyword or something I can do to make the input inhibited stay
on
> until the output is finished?
>
> Thanks in advance,
>
> Craig
>
>