Bottom line: Of all the options provided, the program Scott wrote is going
to be A) most accurate and leaves little doubt about the results, and B)
will be much faster than the other options.
CHKIN/CHKOUT were meant for very different purposes (potentially related to
this but different nonetheless) and are not really suited to the task at
hand, they are workarounds.
As to your question about CHKIN your point is well taken, however the
command does put locks on directories and files and while it is the cure for
some of the problems if that command does not complete normally it leaves
behind problems that you may not know about until it's a crisis. I've had
to recover too many machines were IFS objects were missed on all the
backups, and the error messages ignored as "normal", providing an
unrecoverable system. If critical files were in that list the fun really
begins. Fortunately most of the time the files involved are of a less
important nature that can be rebuilt given other data sources. Still that
leaves too much room for doubt. I avoid those to commands as much as
possible since their relevance today is mute given what most people are
doing.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
CRPence
Sent: Wednesday, April 08, 2015 8:31 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: CL program to check if folder exists in IFS
On 08-Apr-2015 07:29 -0500, Jim Oberholtzer wrote:
If you use CHKIN make really sure you CHKOUT right after that. It'll
mess up backups and more importantly recoveries.
Would not the alluded issue(s) only be possible for the reverse; i.e.
if using Check Out Object (CHKOUT) then ensure an eventual Check In Object
(CHKIN) is also performed? AFaIK there is no ill-effect from performing a
check-in of an object that is not checked-out; the CHKIN request does not
even fail when the specified OBJ() is not checked-out, and merely should be
ineffectual, much like a DLCOBJ [similarly for which any ALCOBJ should be
followed with an eventual DLCOBJ, although locks disappear with the end of
the process, whereas IIRC the status of checked-out persists even across
pwrdwn\IPL sequences.?
Compared to the other options presented, this offers the most
opportunity for trouble.
While I agree that the all too often suggested use of CHKOUT as a /trick/
to test existence [or any other purposes, other than actual intent of
effecting a Check-Out of the object] should be discouraged, I am unaware of
any problems with using CHKIN *except* if the user might have legitimately
performed a prior CHKOUT for which the effect of CHKIN [without their
knowledge nor intent] that might be undesirable.
--
Regards, Chuck
--
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
