Messages

31

Windows Client / Re: Duplicating users

« on: August 26, 2021, 08:21:41 AM »

Greg if possible above my pay grade!!! haha...

And of course our main go to guy for this kind of question is no longer working for the group who would know...Unfortunately everything is going to offshore support.....

32

Windows Client / Duplicating users

« on: August 23, 2021, 09:35:03 AM »

Not sure if this is the correct forum....But here's our issue...

Currently we are using mainframe RACF password authentication for users to access CMOD. (Too long to type WHY this was done years ago by IBM)

In any event we are moving to a new server at our corporation and need to convert ALL user ids that are currently just defined in RACF to their LDAP user id.  This is approx. 800 users.

We are told we need to MANUALLY do this by bringing up their existing "old" RACF mainframe id and doing a COPY and adding their LDAP user id via the ADMINSTATOR session.  That way the keep all their current access that's now in place.

The issue we foresee is if more than one person attempts to do a copy at the same time, we will received the dreaded, "User id or UID already exists"  In this case it would be the UID because it appears if 2 people are attempting to add a new user at the same time, it tries to use the same UID number and this is the error you receive.

Does anyone know how to avoid this from happening so more than one person can be adding users at one time?

Appreciate any help or direction.

33

Windows Client / Re: System Load

« on: May 18, 2021, 10:05:02 AM »

Thanks for the info...We define a POSTING DATE and check the SEGMENT box.  On the Application setup we input a lower case t in the Default value for the POSTING DATE definition under the LOAD INFORMATION tab.  So it will use the LOAD DATE as the POSTING DATE.  But we also have many cases where we are pulling the POSTING DATE off of the data page.  We have recently found numerous setups where we had the POSTING DATE format on the Application as m/d/y which was correct when initially defined.  Unknown to us was the application changed the data to be y/m/d.  We still successfully ingested the data as the length was the same.  But the POSTING DATE was out of order.  So instead of the posting date being 5/18/21, it was being stored as 21/5/18.  The issue was found by our systems support area who saw our CACHE being filled up.  We have report setup to remain on cache for 7 days based and then roll to TSM.  But because of the date format issue, the system never saw the correct date to know to move it off of CACHE.

34

Windows Client / System Load

« on: May 18, 2021, 09:23:57 AM »

Can anyone explain on SYSTEM LOAD search where the information for DOC BEGIN DATE/DOC END DATE & START DATE and END DATE information gets pulled from? In searching the System Load we see MOST of these dates match the LOAD DATE but some do not? We discovered it by accident when trying to determine reports with bad posting dates.  Noticed when looking at the System Load these DOC  BEGIN/END and START /STOP DATES were showing really old dates.  Would it be getting these dates from the actual data?  And if so, how? Is it based off of the POSTING DATE that was defined?

35

Report Indexing / Re: Application group question

« on: May 18, 2021, 06:03:10 AM »

the issue we are having is with the bad Posting Date formats, its never rolling off of CACHE after 7 days.  Apparently it uses the Posting Date as the starting point and after 7 days (what is set on App Grp) it then rolls to TSM for long term storage.

36

Report Indexing / Re: Application group question

« on: May 17, 2021, 06:42:33 AM »

Justin,

I understand the that the indentifier differentiates the different applications that are defined to the application group. And as stated we input the report description as the DISPLAYED VALUE. 

I BELIEVE what our engineering group was looking to do is UNLOAD all the current reports that were loaded to CMOD with bad posting date formats.  We would then update the applications definitions with the correct Posting Date Format.  He would then reload the data back into CMOD so it would have the correct date format for the Posting Date.

We need to get confirmation from him on how exactly the CACHE migration works.  As indicated, we have it set to 7 days.  He is saying with the bad POSTING DATE format its never migrating OFF of CACHE to TSM.  But it appears to use the Life of Data and Indexes expiration tpe is set to LOAD which we interpret to being based on LOAD DATE, correct?

37

Report Indexing / Re: Application group question

« on: May 17, 2021, 04:43:15 AM »

THanks Justin....We were told by or engineering group that they were seeing CACHE being filled up.   We have, on the Application Group for each load to remain on CACHE for 7 days before migrating and because the POSTING DATE format is configured wrong on the Application definition, it is never moving off of CACHE.  We always assumed the migration off of CACHE was based on date the data was loaded into CMOD and not the POSTING DATE that was being used.  As far as use of the Identifier, when we converted off of the old mainframe ONDEMAND to CMOD, IBM handled all the conversion of the existing reports.  They used the REPORT TITLE as the indentifier on the Application group and created it as a FILTER.  The description (ie DISPLAYED VALUE on the Application Group setup was used on the Folder setup.  So we just kept using that when defining new reports.

38

Report Indexing / Application group question

« on: May 16, 2021, 05:03:15 PM »

Hello,

On the Application group, we defined a field called REPORT TITLE where the Database Value is the name of the Application and the Displayed value is the description of the report which then is shown in the folder definition under REPORT TITLE.   We have an Application group with several applications defined to it.  We found an issue with several POSTING DATE formats on numerous applications where the format was setup as %y/%m/%d but at some point the data was changed to be %d%m%y.   we have reports to store initially on CACHE for 7 days before migrating to So when ingested the posting dates are wrong which caused the reports to remain on CACHE instead of migrating to TSM for defined life of long term storage.  What we need to do is create new  definitions with the correct format.  But we also need to keep the existing applications so already loaded data can be accessed.  What we are looking to do is rename the current application definition to, as an example TEST-123.  We then would ADD a new REPORT TITLE database definition called TEST-NEW as the Database Value with the same displayed value as TEST-123.  We would then create a new Application name base of the original name of TEST-123 and use the TEST-NEW as the Application Group Indentifier.   My question is, would this work without causing issues with preloaded data?  And also, what exactly is that INDENTIFIER used for? I've attached a few screen shots for reference.  TY

39

MP Server / Re: APPLICATION GROUP SETTINGS

« on: March 14, 2021, 04:08:30 PM »

Thank you both for your replies!  We did test out the retrieval check box and it matched up with the 66 msg in the log.  It's funny how all these applications seem to come out at once asking if anyone is looking at their reports to determine if they are still needed.  They even go as far as wanting us to provide WHO these people are.  Prime example of them not knowing their user base.   Allot of these reports are old mainframe reports that were converted off the old ONDEMAND system to CMOD,  which was handled by IBM.   And when that was done, they didn't turn on any option on the Application Groups!

40

MP Server / APPLICATION GROUP SETTINGS

« on: March 12, 2021, 07:42:22 AM »

Hello, we had a question from the end user looking to find WHO is viewing at their reports.  So would we want to check the RETRIEVAL box on the Application group and does that correspond to the Msg 66 in the message log?

41

Report Indexing / Re: Loading large CSV using Generic indexer

« on: March 07, 2021, 05:02:50 PM »

Good information to know!!!!….Especially if the application comes back to us blaming CMOD!!!  I appreciate it!!

Take care

42

Report Indexing / Re: Loading large CSV using Generic indexer

« on: March 05, 2021, 08:27:21 AM »

Thanks for the reply!...Not going to bother opening a PMR for this.   Application end is looking to splitting this up in 2 pieces. 

43

Report Indexing / Re: Loading large CSV using Generic indexer

« on: March 05, 2021, 07:38:52 AM »

Agree..changing the max rows made no difference.  After loading file was not able to view all rows in CSV.  We are going back to application to see if they are able to split the file.  If they are resistant, we will have to go to IBM.  As always, appreciate the quick response!!   Take care

Dave

44

Report Indexing / Re: Loading large CSV using Generic indexer

« on: March 05, 2021, 06:23:04 AM »

Justin,

We do have it defined as USER DEFINED (CSV).  We did increase the Max Rows on the Application Group to 20,000,000 and having them retry sending file again.

45

Report Indexing / Re: Loading large CSV using Generic indexer

« on: March 04, 2021, 06:20:06 PM »

10.1.0.5