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



Thanks Chuck;

Yes I totally understand your arguments and maybe they are proper for OS400.

I think that an analogy to real 3d objects (like a car) may have intrinsic issues though.

I would say an analogy to a similar type of entity may be more appropriate.

Lets take a customer master file with a record-created date-stamp on each row. Older customers were added in 1995, newer customers were added in 2012.

Export it to another same-OS system during a hardware upgrade.

Now when you go to look at the customer file, EACH ROW is stamped July 19, 2013.

Well, yes that's accurate, because each row was definitely added today - to the target system.

But that is NOT how the IT world works.

The create-date for each entity (customer row) should be (and always is) the date that a user added the row - such as 1995.

One could argue (as everyone is on this list) that NO, the record in the target system was added today, so each row should be stamped 2013.

This example should scale upwards to row, table, file, library, system, whatever. Each level should behave the same from a single-fact record to an entire enterprise.



There is no right or wrong, and with a few therapy session spaced out over several months, I will get past this :)

Hey its Friday right?


It just doesn't seem right that SAV/RST alters an object and loses the days-used counts and last-used-date sometimes (when restoring to different lib) and other times retains that info.

Especially when objects have OTHER independent fields for last-save date.

People move files and objects around constantly for machine upgrades, corporate mergers, lots of reasons. People also use the last-used date to keep libraries clean and to not get them cluttered too much. By IBM commands stepping on this info, it makes it difficult to keep systems clean of old junk.

But maybe that's the point - sell more disk storage???






-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, July 19, 2013 12:09 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: CRTDUPOBJ: how to retain the create date and usage info

On 19 Jul 2013 09:21, Stone, Joel wrote:
Maybe I am all wrong, don't know. But in Win7, the date shown on
Windows Explorer keeps the history.

In OS400, it seems all history is purged with CRTDUPOBJ and/or
SAVOBJ/RSTOBJ.

<<SNIP>>

Not /wrong/ per se, but certainly overlooking the obvious distinction
of the IBM i OS as compared to many others. To be clear, the IBM i
[OS/400, S/38] origin, is as an *object-based* system; quite different
than most other.

Consider any tangible /object/ in everyday life, perhaps for example,
a classic car. If someone creates a duplicate of that car, what exactly
are the creation date, change date, and last-used date for both the old
car and the new car? IMNSHO there is *no logical way* to argue that
they should be the same.

Perhaps however there were some stickers on the rear\inside of the
driver-side door which indicate the manufacture-date [and perhaps
equivalents of the other attributes]. Arguably a /duplicate/ of that
car which intends to fully mimic the old car might want to have its new
stickers reflect the same values that are recorded on the original\old
car. As I noted in my prior reply however, such additional attributes
are separate from the known\reality, and there would be no integrity in
referencing that sticker as an accurate reflection of reality, because
the new sticker with the copied values would be a misrepresentation;
i.e. the copied dates portray a false claim.


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.