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



There were certainly issues many years ago, especially across libraries but
I haven't heard of any since the '90's.


Norm Dennis

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeff Crosby
Sent: Monday, 1 October 2012 9:07 PM
To: Midrange Systems Technical Discussion
Subject: Re: confusion with logical files and crtdupobj

In 20+ years on OS/400 and now IBM i, I have never had an issue with the
results of CRTDUPOBJ.

But I always, and I do mean always, put LF in the same library as the based
on PF.


On Sat, Sep 29, 2012 at 2:27 PM, Gary Thompson <gthompson@xxxxxxxxxxx>wrote:

Jeffrey, your points are well taken.

I agree, using CRTDUPOBJ is something like "carving soap with a razor
blade",
and checking DB Relations to verify results is a best practice
for all
LF create actions (DDS and/or SQL), but I actually do trust
CRTDUPOBJ,
but do not trust >me<.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeffrey Tickner
Sent: Saturday, September 29, 2012 12:07 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: confusion with logical files and crtdupobj

CRTDUPOBJ and LFs will not always work. Speaking from over 14 years in
CM on i where CRTDUPOBJ is a common method for putting objects in
place on the production server, you JUST CAN'T TRUST IT. I would
normally recommend that LFs be the only object type that the source
was sent over and the object compiled into place. Had one customer who
did NOT have any compiler installed on the production server, yes they had
problems.
If you look at the help on CRTDUPOBJ IBM qualifies what will happen
with LFs and describes exactly what happened in your case.

When a logical file is copied into another library, two cases
determine the basing for the file:

1. If both the logical file and its based-on physical file are
originally in the same library, a duplicate of the physical
file must be created in the new library before a duplicate of
the logical file is created. After these two duplicates are
created, the new logical file is based on the new physical
file.

2. If the logical file and its based-on physical file are
originally in different libraries, it is not necessary to
duplicate the physical file before duplicating the logical
file. In this case, the duplicated logical file is based on
the same physical file as was the original logical file.
Unlike the first case, even if the physical file is copied
into the new library before the logical file is copied, the
duplicated logical file is based on the original physical
file, not on the duplicated physical file.

I swear the Help used to say you should always check the database
relations after using CRTDUPOBJ on a LF...
because you shouldn't trust it.

only print this email if really necessary Jeffrey TICKNER Technical
Resource jtickner@xxxxxxxxxxxxxxxxx

55, rue Adrastée - Parc Altais F-74650 1, Phoenix Mill Lane - Suite
203 - CHAVANOD
Peterborough NH 03458 - USA
Tel. +33 (0)4 50 57 83 96
Tel. + 1 603 371 9074 ext 505
Cell. +33 (0)6 11 15 69 59
Toll. free +1 800 676 4709 ext 505

***This e-mail and its attached documents are confidential and
intended solely for the use of the addressee(s). ARCAD Software can in
no way be held responsible for any damage resulting from an incident
involving security, integrity, virus or transmission delay. As the
integrity of this message cannot be guaranteed on Internet, the ARCAD
Software company cannot be held responsible for its contents. Any
unauthorized use or dissemination is prohibited.***




--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at http://archive.midrange.com/midrange-l.



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.




--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.



-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2677 / Virus Database: 2591/5293 - Release Date: 09/26/12



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.