Re: jt400.jar in use

Today, a different single file was not saved. It was:

/QIBM/ProdData/OS/OSGi/LWI71/runtime/isc/eclipse/plugins/com.ibm.isclite_7.1.1.6.jar

The jt400.jar file that was NOT saved yesterday WAS saved today. I made no
changes.

And the BRMS recovery report run this morning says I need both yesterday's
and today's tape for recovery. I thought "good news!" in that it would
tell me I needed yesterday's tape to recover the file mentioned above. But
it was not to be. The reason BRMS says I need yesterday's tape is because
I deleted an old test library yesterday. I need yesterday's tape to
restore that now deleted library. No reference to needing it for *LINK
restore.

Evidently BRMS doesn't keep data to the same level of granularity on *LINK.
I may just open a PMR later and see what the IBM BRMS people have to say
on this.



On Tue, Jan 29, 2013 at 12:32 PM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>wrote:

Dan & Jim,

I understand what you are saying with regard to not worrying about saving
this file, jt400.jar, but I'm just not comfortable with it. I don't want
to start a list of files that I have to go find somewhere when a recovery
is necessary. Not even one.

In addition, the recovery report generated by BRMS after this morning's
backup states the only tape I need for recovery is the tape I used this
morning. Even though jt400.jar was not saved. The recovery report should
also tell me that I need the tape used yesterday morning when jt400.jar WAS
saved. Why doesn't it tell me that? I simply don't understand why. What
else isn't BRMS telling me? I looked at the WRKLNKBRM command and drilled
down to the jt400.jar file in question. It is listed on the tape used this
morning as size 0 bytes, and says it was NOT saved. It does show under
yesterday's tape as being saved. Again, why doesn't BRMS tell me I need
yesterday's tape? This situation, all by itself, really makes me nervous.

People keep telling me not to worry about this file or that file or that
directory. Performance data and log files I understand. I just can't make
myself go further with it.

My goal was to do a complete 100% save of the system 5 mornings a week,
with as little downtime as possible. I'm slowly coming to the conclusion
it cannot be done, unless I do the entire backup completely restricted.
That's what I'm doing now without all this study and testing. I'm not
sure where I'm heading now. Do this "new" BRMS control group Mon-Thu and
do the old, completely restricted, BRMS control group on Fridays? I just
don't know.






On Tue, Jan 29, 2013 at 10:18 AM, Jack Kingsley <iseriesflorida@xxxxxxxxx>wrote:

Jeff, did a little more on this, looks like this ifs
directory(/QOpenSys/QIBM/ProdData/acsi) is default for a product called
IBM
Tivoli Directory Integrator.


http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=%2Fcom.ibm.IBMDI.doc_6.1.1%2Fpdguide17.htm



On Tue, Jan 29, 2013 at 10:07 AM, Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx> wrote:

I agree with Dan. Exclude it from your save since it is easily
recovered in other ways, and does not change very often. Your
monthly/Quarterly full system saves should be plenty. (or after a
group/cumulative installation)

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 1/29/2013 9:01 AM, Dan Kimmel wrote:

Don't worry about backing it up every day. It changes only via PTF. It

is easily recovered if necessary.

jt400.jar is the Toolkit for Java. It contains the JDBC database

drivers

for Java as well as a whole bunch of java classes for accessing IBMi

API's.

It might have been in use from iNav or one of the HTTPSVR instances.

-----Original Message-----
From:midrange-l-bounces@xxxxxxxxxxxx [mailto:

midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeff Crosby

Sent: Tuesday, January 29, 2013 8:50 AM
To: Midrange Systems Technical Discussion
Subject: jt400.jar in use

All,

I've spent a couple of weeks re-engineering our nightly BRMS backup to

be as much save-while-active (SWA) as possible (the subject of a rather
long thread here).

I put it in production today and it ran flawlessly except for one

little

hiccup. This *LINK object, /QOpenSys/QIBM/ProdData/acsi/lib/jt400.jar,

was

not saved because it was in use. This was at 4:19am with no users

signed

on. Controlling subsystem would have been started about 1 hour earlier,
and subsystem QHTTPSVR would have been ended when the error occurred.

When I drilled down in Navigator, it did indicate the file had been

used

today, but does not give a time. There is no WRKOBJLCK equivalent for

IFS

files, but I found this online CALL QP0FPTOS PARM(*LSTOBJREF
'/ifspath/ifsfile' *FORMAT2) that showed me there were no locks on it

now.

<g>

I had tested the *LINK save as SWA close to a dozen times over the

past

10 days and this particular file never showed up as being in use. My
question is, essentially, why today? Was this a fluke? How can I find

out

what was using this file at that time?

I did download and stage the latest Java group PTF yesterday

afternoon,

to be applied the next IPL, if that makes a difference.

I just don't want this file getting missed every day.


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

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