I was wondering if someone would mention this. When copying data, I've
always removed the file member on a logical and then re-added it at the
destination. Never a problem. I hate it when it's in a different library
than the physical but sometimes a necessity when dealing with packaged apps.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan Kimmel
Sent: Monday, October 01, 2012 9:12 AM
To: Midrange Systems Technical Discussion
Subject: RE: confusion with logical files and crtdupobj
It's a shame CPYF doesn't have a *NONE option for member. The appropriate
way to copy a logical would be to CPYF FROMFILE(FROMLIB/ORIGINAL)
TOFILE(TOLIB/ORIGINAL) FROMMBR(*NONE) CRTFILE(*YES) and then ADDLFM to point
the logical to the appropriate physical. That way, you'd always be sure your
copied logical pointed to the physical you want.
I have deleted the members of a logical (RMVM), copied it, and then ADDLFM
to both the original and the copy. You have to DSPFD the logical first to
see where the members are currently pointing (based on file). Note that RMVM
doesn't work if the logical was created as an SQL view.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Gary Thompson
Sent: Saturday, September 29, 2012 1:27 PM
To: Midrange Systems Technical Discussion
Subject: RE: confusion with logical files and crtdupobj
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.
--
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.
midrange.com
