Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - jsquizz

Pages: 1 ... 7 8 9 10 11 [12] 13 14 15 16 17 ... 37
166
I've seen this done before using arsuload, indexes extracted via C exit and ftp back to business to verify loading

capture the load id from the load, parse the loadID and retrieve it from the data table..? if that makes sense

167
MP Server / Reconciliation via arsdoc query
« on: August 14, 2020, 09:07:27 AM »
This isn't rocket science or reinventing the wheel, but I have a request to verify that a series of documents are loaded, or are not loaded into CMOD.

I approached this as basic as possible, I have a list like this that I loop through ARSDOC query, when the response is less than 1, I then echo the "missing" metadata to a text file for the business to resend. That part works fine.

12341234,313433
12341333,312343
12343333,331111

My problem is that they have 200,000,000 rows they need to validate. Using arsdoc query + bash, this is extremely slow as I expected. It would take 1month to complete going 24/7

We could go through the database tables directly, which is probably what our DBA will want us to do. Just wondering if anyone else has any good ideas.

168
MP Server / Re: Search to see if old versions are being viewed by users
« on: August 03, 2020, 02:51:49 PM »
Shouldn't be too hard to script

I would parse out the doc_name/ag from the 66 message..

Throw it back into an arsdoc query against the system load folder..that should give you what you need

169
MP Server / Re: Admin client cannot connect to VM (local)
« on: July 09, 2020, 11:04:28 AM »
If your version of RHEL has changed, they often make dramatic changes in how firewall commands are issued.  You may need to update your cookbook.  In the past it's been iptables or ufw, now there's a 'firewall-cmd' command.

-JD.

Thanks, I will take a look

170
MP Server / Re: Admin client cannot connect to VM (local)
« on: July 08, 2020, 01:01:22 PM »
Probably need to open port 1445 on the Linux OS firewall.

-JD.

Tired that :) One of the first things I did when I stood the box up.

In the past, I've set some VM's up the SAME EXACT way, but didnt have this issue.

171
MP Server / Admin client cannot connect to VM (local)
« on: July 08, 2020, 11:00:48 AM »
Strange issue here-

On my Desktop - I'm running a RHEL VM on VMware Workstation ... with CMOD 10.1 and DB2. Everything is up and runnign fine.

I can putty in from my desktop where the VM is running, and my laptop across my network. But I cannot connect to the admin client. Suspect it's a simple network/firewall on the windows 10 PC's, but not sure.

Also - Could it be a connection setting in the VM that I have to work?

172
iSeries / Re: Question regarding stash files
« on: July 07, 2020, 02:20:23 PM »

Also, it's not a good idea to create a stash file for the admin account.  Someone who can read the stash file can use it to do anything they want (reset another user's passwords, delete data, etc.)  It's better to create a user for a specific role, and assign the minimum access required (say, to work with a specific Application Group) to accomplish the task.



thanks for this.

Shame on installs I've worked on, using "admin" to run arsload/arsdoc, and do the admin work..:D

173
iSeries / Re: Question regarding stash files
« on: July 07, 2020, 12:49:32 PM »
stash file holds encrypted passwords. So, you'd add the username/password thats defined in the admin client to the stash file. Then when you do your commands, you use the -p flag and point it to the stash file. That's how I always do it

I pulled this from my sandbox cmod, only one i have up right now.

arsstash -a 1 -u admin -s /path/to/ars.stash

it will then prompt you for the password.

174
MP Server / Re: db2move vs backup and restore
« on: July 06, 2020, 05:46:27 PM »
The readers digest versions is that when sticking with the same platform backup and restore works. It's when switching platforms that db2move comes in handy.

-RR

Great. Thought so.

I'm assuming that once I get the backup and restore done I just need to use arsdb to upgrade the tables and do massaging that way?

175
MP Server / db2move vs backup and restore
« on: July 06, 2020, 11:10:36 AM »
Looking at doing a migration between two boxes. I've only done the extract/reload method before.

One of the ways I did this back in 2015.. In a windows environment, was I used db2look/db2move to extract the old 8.5 tables to a fresh 9.5 box. After that, I just made sure the cache file systems are lined up in the config files.

My newest task is doing the same thing in a linux environment. One of my colleagues who is a db2 dba also, suggested doing a db2 backup and restore on the old db and restoring to the new. I'm confident it might work, especially because we are going from linux to linux. We also are only using cache file systems..But we have about 100TB.

Existing - 9.5 RHEL 6...?, DB2 11.1
New - 10.1, RHEL 7.3, DB2 11.1

Any thoughts on doing db2look/db2move vs backup and restore?

Thanks!

176
MP Server / Re: Default location for trace file?
« on: July 02, 2020, 01:00:09 PM »
Without specifying a full path, I would expect the trace log to be generated in the directory you were in when you ran the arssockd command.

Why not just change the file to include a full path?  :)  Somewhere with wide open permissions like /arstmp or /tmp.

If it's not able to create the trace file, it probably doesn't have permissions to write the file there.

-JD.

I figured that too. We need to turn trace off because for some reason it's been running in production. I'm just really curious as to where the trace file is being generated.

177
MP Server / Re: Default location for trace file?
« on: July 02, 2020, 11:22:10 AM »
Did you search in /tmp ?

Usually the trace files is wrote in /tmp when is not set on trace.settings

Lair Martins
IBM Brazil

Yeah, It's not there. I thought the same thing. There's no trace file at all being generated.

178
MP Server / Default location for trace file?
« on: July 02, 2020, 09:57:53 AM »
We are running trace, and I'm trying to figure out where the file is output to. It's set to -

    [TRACE]
TRACE_FILE=ARCHIVE.trace.log
TRACE_LEVELS=DB=3,SOCKET=3,SRVR=3

I verified it's running. But Can't find the file. In reading the documentation (if i understand it correctly), it shold goto ARS_TMP..which It's not.

It's also not in /config and /bin .. My thoughts are its writing somewhere and it might fill up a file system. We have to run arsmaint to purge 100mil+ docs, and that smells like trouble to me.

anyone have any thoughts?

179
Report Indexing / Re: PDF Indexer
« on: June 22, 2020, 11:31:01 AM »
I tried this for a POC.

It probably wont install through the installer, it will yell about version differences.

180
MP Server / Re: ARS0114E Unable to open file
« on: June 18, 2020, 07:17:43 AM »
Quick tidbit,

many, many moons ago- one of our SA's set /ARSCACHE to 775 for some reason.

Loading/retrievals were giving all kinds of errors..similar to yours

Pages: 1 ... 7 8 9 10 11 [12] 13 14 15 16 17 ... 37