RE: DSPF Handling (was Re: Design shift of view)

> Let me see if I've got this right.  In your example you'd be able to change 
>the properties
> of the date field and it would then be instantly accessible wherever it was 
>referenced.
> You wouldn't have to:
>    Recompile the field reference file.
>    Recompile all physical, printer and display files that refer to that 
>'object'.
>    Recompile all logical files.
>    Recompile all programs.

Yes. If IBM changes the machine instructions that handle a date to increase 
performance,
all date fields get these improvements without recompiling. If you change a 
trigger program,
the database uses the new program (once the activation / trigger pgm end of 
course). I
don't see why this would be any different. I think of it as almost a field 
level trigger.

> I have to confess an ignorance of VARPG, BIFs and the like.  Perhaps that 
>opening, and
> the fact that I've been on IBM midrange for over a dozen years now, will 
>explain the
> paradigm of my next query.

> Is this kind of modularity attainable?  Will it perform to the users 
>satisfaction?

Lets keep in mind that this thread started as a "thinking outside of the box" 
exercise.
I'm sure it deviated from the original thread considerably. I was not trying to 
find a
solution that easily fit into the current environment, was efficient, etc. 
Rather I was
stating what I would like to see if there were no limits on what could be. I'm 
not the
person to answer whether it's feasible or even likely. IBM's answer is do it on 
a PC.
I don't see that answer being widely accepted at this point. Most of the shops 
that I
see doing this, are doing it with Oracle and NT or UNIX, not on AS/400s.

> For example. I moved from straight RPG on the S/36 to RPGIII on the S/36 using
> software by ASNA.  I grew to love the program modularity attainable with the
> CALL statement. You could change this program and not have to recompile
> everything, versus the /COPY method.  Now I see the CALL going by the wayside
> to procedures and CALLB and the like. Back to recompiling or rebinding or 
>whatever.
> I see objects on the 400, and on PC's, growing huge in size, often performing 
>the
> same functionality.

Binding modules and CALLBs are a response to machine performance, not a
productivity gain for developers. I don't really use CALLB and bindable modules
that much. I've already accounted for this by leaving LR off in programs. 
Procedures,
Service Programs and the new RPG/ILE syntax are productivity gains. Other recent
additions that are big hits are triggers, stored procedures, commitment 
control. I know
that these are not all new concepts, but they are in many AS/400 shops.

Joe Teff
Information Technology Consultant
IBM Certified Specialist - AS/400 RPG Programmer
Quality Data Systems
Minneapolis, MN

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