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



| -----Original Message-----
| [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Tom Liotta


| >For wish list: I wish DDS level-check calculation had same *PREVIOUS
| >binder-source facility that ILE programs had, so fields could be added at
| >end (as they ALWAYS should be), WithOut causing a level check in
| a pgm that
| >doesn't need the new fields.

| Isn't this a practical side-effect of DDS LFs anyway? As long as
| (1) the LF _explicitly_ lists fields and (2) programs use the LF
| to access the data, there should be no problems if new fields are
| added to the PF nor if the fields are rearranged in the PF. (It
| doesn't matter if fields are added at the end, in the middle or wherever.)

That's correct, and was the standard in the first 38 shop I worked in
(Liebert in '82).  There are other benefits as well, such as making it more
convenient to do multi-format LF and join LF.  However afaik, most shops
doing this would normally have the added overhead of an organized and
maintained central FldRef file or "Data Dictionary".

| If the new field is needed in a given program, that program
| obviously needs to be recompiled anyway. Create a new LF to
| include the new field. Ideally, the access path will be shared
| with the old LF, so nothing much is really added to the system --
| just a new data definition.

Yeah, no extra load on the CPU for the new LF.

Although I had a utility to make LF source from PF src, I would say that I
haven't used this practice since mid-to-late-80's much.  I had a utility
that did most of what ChgPF SrcMbr(x) does and which LvlChk'd everything to
*NO.  Then I'd run a mass-compile through Hawkeye (or equivalent, if any)
and run the Cmd to ChgLvlChk back to *YES.  (Why for you'd need a make
facility, I dunno, unless you don't have real-time tools to regen a system
like I've become spoilt by over the years...?...;-)


| Programs using old LFs shouldn't need to be recompiled although
| the old LFs themselves do (though I'm not clear why they _have_
| to be other than that's the way DB2/400 was written.)

I don't think they do need recompiled if they use old LFs with the fields
specified explicitly... ?  Also, the main reason I switched to ChgPF is that
it's my (partial) understanding IBM does some pointer switching to avoid
rebuilding the access paths (unless necessary).  I believe Turnover and
others have similiar capability or better.

|
| Tom Liotta
|
| --
| Tom Liotta
| The PowerTech Group, Inc.
| 19426 68th Avenue South
| Kent, WA 98032
| Phone  253-872-7788 x313
| Fax    253-872-7904
| http://www.powertech.com




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.