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



I think the easiest thing to do here is an externally described print file.
Once I remembered I had Code Designer, it didn't seem so awful. <g>

I could have used global variables and done it in a subroutine.  I'm trying
to force myself to use subprocedures more, regardless of whether they're
appropriate. <g> 

 

> -----Original Message-----
> From: Scott Klement [mailto:klemscot@xxxxxxxxxxxx]
> Sent: Monday, March 10, 2003 4:01 PM
> To: RPG programming on the AS400 / iSeries
> Subject: Re: o specs in sub procedure
> 
> 
> 
> On Mon, 10 Mar 2003, Joel Fritz wrote:
> >
> > The from value comes from a data structure defined in the 
> procedure.  It
> > looks like the O specs want global variables.  That makes 
> sense.  Seems like
> > overkill to write a print file.  I can also define a global 
> variable used
> > only in the file update procedure.  That doesn't really 
> excite me either.
> >
> >
> 
> Yes, files in RPG are global.   You need to use global 
> variables if you
> want to write data to them.
> 
> Here are a few thoughts:
> 
> 1)  You could just have *one* global variable for printer output.   A
>       string defined as 132A (for example) would work nicely.   Then
>       populate it from your data structure with statements like:
> 
>         eval  printme = *blanks
>         eval  %subst(printme: 1) = %editc(ds_value1: 'L')
>         eval  %subst(printme: 10) = %editc(ds_value2: 'M')
> 
>       This is *almost* like having o-specs in your subprocedure.
>       Of course, you'll want to do an EXCEPT once all of the fields
>       have been populated.
> 
> 
> 2) use a service program or module that's just for printing.  Since
>       global variables are global to the *module (as opposed to the
>       entire program) you are restricting the variables to just the
>       one procedure.   (This is awkward IMHO, but it's a thought)
> 
> 3) use the ILE C routines to create files that *are* local to your
>       subprocedure.  (This is probably too much work and/or too much
>       of a learning curve -- but I thought I'd throw it out there)
> 
> 4) write the output to a stream file instead of a spooled file.
>       Of course, then it doesn't print without you doing extra work,
>       but sometimes this is useful, like if the user wants to just
>       grab the file and open it in notepad or something, and then
>       print it from there...
> 
> I guess a lot depends on the application and/or why you don't want to
> use global variables.
> 
> 
NOTICE:
All e-mail sent to or from this e-mail address will be received or otherwise
recorded 
by The Sharper Image corporate e-mail system and is subject to archival, 
monitoring, review by and/or disclosure to Sharper Image security and other 
management. This message is intended only for the use of the addressee and
may 
contain information that is privileged and confidential. The contents of
this message 
may contain personal views which are not the views of The Sharper Image. If
you are 
not the intended recipient, dissemination of this communication is
prohibited.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.