×
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.
We also have an issue with data areas and data queues. Fortunately, they are only -mostly- locked! My two favorite conjectures as to the cause are (a) running backups on the target machine, and (2) users looking at them on the target machine for long periods of time. I suspect the backups because the objects never seem to get locked during the day, but they're almost always on hold in the morning.
I hadn't considered the objects being locked on the source side, but that's equally plausible!
Files tend to get locked on the target side because users and developers are allowed to look at the data. And they look... and look... and look. Then they go home and leave their sessions running!
For the data areas and data queues that go on hold (you see them by keying 53 on the Work With Data Groups screen) I wrote a program to automatically retry the options. Here are the highlights:
DCL &DATAGROUP *CHAR 10 contains the data group name with the items on hold
DCL &SYS1 *CHAR 8 name of the "from" system
DCL &SYS2 *CHAR 8 name of the "to" system
DCLF FILE(MIMIX/MXDGOBJTE)
First step: WRKDGOBJTE DGDFN(&DATAGROUP &SYS1 &SYS2) +
STSVAL(*HLDERR) OUTPUT(*OUTFILE) +
OUTFILE(QTEMP/OBJONHOLD)
"Work with Data Group Object Tracking Entries"
This creates a file with the names of all the 'type 53' items on hold.
Override MXDGOBJTE to the file just created in QTEMP. Loop through the file and issue the following command for each entry to tell MIMIX to try and re-sync the object:
SETDGOBJTE DGDFN(&DGDFN &DGSYS1 &DGSYS2) +
OBJ1(&LIB1/&OBJ1) OBJTYPE(&TYPE) +
ACTION(*RLS) TYPE(*IMMED)
This issues an 'option 26' (Release) for all of the objects found. All of the variables here are from the "OBJONHOLD" file
If the objects have been sitting on hold for a while it might take MIMIX a while to go back and find the outstanding entries. We have this running every half hour to try and keep up with anything on hold. Most of our activity is overnight, it's rare for anything to go on hold during the day.
Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of A Paul
Sent: Friday, October 11, 2013 12:01 AM
To: midrange-l@xxxxxxxxxxxx
Subject: MImix
Due to locking issues we go out of sync for nearly 50 objects on Mimix. Data areas and data queues are difficult as they are always locked. The files have to be pushed manually. Is there any solution to prevent this situation?
What reports we can look at besides monitoring the mimix for the objects not mimixed ?
As an Amazon Associate we earn from qualifying purchases.
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.