|
Vern,
I do have front ends that bring up those control records. And they do only
show what I want shown.
On Fri, May 13, 2011 at 12:43 PM, Vern Hamberg<vhamberg@xxxxxxxxxxx> wrote:
Hi Jeff
The use of data areas varies according to your kind of shop, I think.
When everything is in-house, then using copy members and the like might
be fine. I think for a vendor, things are different. One could use a
single-record control file, but then you need some way to maintain it -
DFU works, as does OpsNav, but a front-end is probably better. Again, in
our case, we have some commands wrapped around the CHGDTAARA, but it'd
be cool to have a menu option that brings up panels with all the values
we want people to manage - same kind of thing could be used with
control-record files.
Eh?
Vern
On 5/13/2011 11:17 AM, Jeff Crosby wrote:
I don't.(Les
I have individual application single record control files to store thing
like last invoice number used, current billing date, etc.
Other things are defined as constants and stored in copy members. An
example of this is we use route 995 for customer pickups. So in a copy
member I have
D @PkpRot C 995
And yes, I know the @ could cause a problem if we go multinational, but I
don't see that happening.
On Fri, May 13, 2011 at 11:17 AM, Birgitta Hauser<Hauser@xxxxxxxxxxxxxxx
wrote:
Hi guys,
we just had a discussion about using data areas.
In my opinion they are not heavily used or needed.
I either create a table/physical file or store the information in global
variables in a specific service program. The data within these global
variables is set and retrieved by calling procedures.
I’m just curious, are you using data areas (heavily) or not?
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars."
themBrown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training
and keeping them!"
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.