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



Some of these program-described printer files are a real pain, aren't they? The fetch is relatively easy to consider; it's all of the indicators that condition the heading or line, and indicators on fields really get nasty.

But back to the Fetch. There is no equivalent to Fetch in externally-described printer files. But, then, there is no inherent equivalent to overflow, is there? The Fetch on the output detail line simply means, "Hey, are there any lines conditioned on an overflow indicator defined for a printer file?" Once the detail line is printed the cycle (oops, here we go again) searches the output specs for this situation if overflow is on. The cycle, also, turns off overflow automatically for program-described printer files.

Externally-described printer files are simply separate record formats for each possible line on the report/form. The printer file usually has overflow conditioned with something like:

FARL002P O E PRINTER OFLIND(@Over)

Personally, within the program before printing a detail line I'll do this:

IF @over = *On;
WRITE Header;
@Over = *Off;
ENDIF;

This is the equivalent of the Fetch. By the way, I do this *before* writing the DETAIL record format so that I don't wind up with "orphan" headers, which can occur when writing the last detail record turns on overflow.

Program-described printer files are much easier to convert, obviously, if the program uses the EXCPT method. The example you gave, Adam, are typical of old-fashioned (even for RPG II) code. I have to deal with this kind of thing, too, in an old, still /36 environment application. Trying to convert the program-described printer files to externally-described is usually not worth the effort, even when I convert the RPG II program to IV. Usually I just leave the printer file program-described. But, if I had to convert it to externally-described, as you seem destined to do (and I have had to do for other reasons), re-writing the program may be the best (only?) way to go. That, of course, is often easier said than done.

Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Adam West
Sent: Tuesday, May 20, 2008 2:18 PM
To: RPG programming on the AS400 / iSeries
Subject: also have the Fetch issue

Externally def. is needed for the Bar code.



What role would the "F" for FETCH play on that Externally Described PRTF if any?

--- On Tue, 5/20/08, Willie J. Moore <WJMoore@xxxxxxxxxxxx> wrote:

From: Willie J. Moore <WJMoore@xxxxxxxxxxxx>
Subject: RE: Converting O specs to PRTF
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Date: Tuesday, May 20, 2008, 6:49 PM

This is using the RPG cycle. So it starts at the top of the 'REPORT' and
check each step to see if it needs to print.
Even if you convert it, you will still need to check/set the indicators on/off
in your program.
If you are changing the RPG code to LE, it is the best time to change to the
WRITE option for printing.
You could just use the CVTRPGSRC command and convert to LE and be done with it,
unless you must have the print file externally defined.
William...

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Adam West
Sent: Tuesday, May 20, 2008 10:53 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Converting O specs to PRTF


THis is sone legacy code to make over to a PRTF. It doesn't use the

Except. I guess it is based on those indicators, then it prints if *IN50
is on and *95 is off ?

How would I convert this puppy?



OREPORT D 105 50N95
O* 88 40 'SERVICE CTR'

O N47 31 'SERVICE INC.'

O 55N47 31 'DESIGN INC. '

O 47 XADR1 30
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


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.