Messages

76

MP Server / Re: Unable to store object Failure

« on: January 29, 2019, 03:46:12 AM »

Justin,

I agree...Sounded like a canned response to pretty much wash their hands of any responsibility..lol....It's funny how these errors hit...Seem to come in spurts..Last one we had was 01/26 and then before that was 01/21...But on 01/19 we has 16...Our main concern is if they hit during off hours where there is a potential of the mainframe jobs rerunning and overwriting old data that didn't get loaded..I'll pass your info onto our engineering group...See how they want to pursue it...As always, appreciate the response!!!

Take care

Dave

77

MP Server / Unable to store object Failure

« on: January 28, 2019, 08:48:28 AM »

I may have posted something on this subject before but it started rearing its ugly head again....We periodically get this type of failure...In most cases we can rename the .failed file and when doing so, the file will always load successfully (at least up till now)...Our issue is, we still have reports coming from the mainframe to CMOD which use OS/390...When this type of file fails, the mainframe job itself has to be rerun manually.  We risk the possibility of losing data in the event the job runs multiple times and data from failed job gets overwritten.  Our engineering group contacted ECS storage...here was their response:

"This represents a failure rate of 0.02  for clip writes and  0.01 for blob writes
We generally advertise ECS availability of 99.9% which you are well within
There is no concern here. The application will automatically retry these failures which will succeed upon retry". 

The main issue here is, ERR doesn't support automatic retry...Our options are to manually rename .failed file or manually re-run mainframe job.

Anyone else using ECS storage having any issues?

Appreciate any feedback

Dave

78

Content Navigator / Re: Downloading a report

« on: January 24, 2019, 06:15:27 AM »

Interesting...This seems it would give us what we can get now with the thick client....Need to talk to my engineers to see if/when we can get ICN 3.0.5!   Can't thank you enough for pointing this out...

Take care

Dave

79

Content Navigator / Re: Downloading a report

« on: January 23, 2019, 11:44:39 AM »

Dang work blocks link....Guessing because its TWITTER...lol

80

Content Navigator / Re: Downloading a report

« on: January 23, 2019, 11:40:32 AM »

I will do that....Looks like we are running Version: 2.0.3 Build: icn203.813.478

Thanks as always Justin!!!

Take care

Dave

81

Content Navigator / Downloading a report

« on: January 23, 2019, 09:48:24 AM »

We have a report on CMOD that is stored as application/line data...Users are viewing the report via CONTENT NAVIGATOR...One user was wanting to download multiple versions to one CSV file...After highlighting the versions that are wanted and then doing a right click. Download, the only option we see in Content Navigator is ORIGINAL and PDF (Grayed out)...Trying as an original it attempts to download each individual version into its own .txt file..But since this is line data, its unreadable...We as Admins have the thick client.  It allows you to highlight multiple versions at one time, right click and then 'Export document data for all selected as csv file)...It then opens one CSV with all highlighted versions data within.  Does anyone know of an option in Content Navigator that allows the same thing? 

Thanks,   Dave

82

Report Indexing / Re: INDEX FIELDS REFERENCE OUTSIDE OF THE RECORD

« on: December 14, 2018, 06:37:30 AM »

we finally determined the issue was the trigger we were using (ACCOUNT:) happened to fall sporatically on another page, ironically within the record range..So we just had to use a different Trigger field that was on the indexing page instead of using ACCOUNT:...We will need to find a tool for really large files in the event we have an issue like this again.  Appreciate the info!!!  Take care

83

Report Indexing / Re: HELP!

« on: December 14, 2018, 06:14:22 AM »

We run this data through the report wizard..Its txt file so its setup as LINE data with a RECFM of Steam (0A)...With thought we could just change the trigger directly from the indexer setup on the application definition..But after trying different fields as a new trigger it always got the same 88 msg...So what we ended up doing is running the data again through the report wizard and highlighting and then setting the new trigger...then ran through the rest of the process defining all the fields and indexes...After doing so, the file ingested successfully...Thanks for responding!

84

Report Indexing / HELP!

« on: December 13, 2018, 12:34:35 PM »

Ok, I'm about to pull my hair out here...We have a report where we were getting all the indexes off of one page.  We were using one of the fields (ACCOUNT) as a trigger and  then going from there to get the other indexes...We had to use set it as a FLOAT with a Record Range 

 TRIGGER2=*,2,X'4143434F554E543A',(TYPE=GROUP,RECORDRANGE=(1,8))     /* ACCOUNT:     */   

What happened was on some of the files, this word ACCOUNT falls on a page in the same position that's not an index page which caused it to fail...What we TRIED to so is use the next line below ACCOUNT which is also fields....All we did was update the trigger line with the new HEX value for the new Trigger (CORR. BIC)

TRIGGER2=*,2,X'C3D6D9D94B40C2C9C3',(TYPE=GROUP,RECORDRANGE=(1,9))      /* CORR. BIC */

We then adjusted the lines on the FIELDS to go off the new trigger..Which meant decreasing each field by one   ...But since doing this, we cant get anything to load...This is all we get in the 88 MSG

APK440I ACIF AT IPTR923 HAS COMPLETED NORMALLY WITH RETURN CODE 0.
ARS4308I Indexing completed
ARS4312I Loading started, 15762 bytes to process
ARS1146I Loaded 0 rows into the database
ARS4311E Loading failed

For the life of me cant understand why it wont load anything now just by changing the trigger and field positions...Just to test again, we even tried using the field below (SPECIAL) as the new trigger, made the FIELD position changes and it still gets the generic failure...Wish it would give SOME kind of information on the actual error!!

I've attached the page we are using for indexing
                  

85

Report Indexing / INDEX FIELDS REFERENCE OUTSIDE OF THE RECORD

« on: December 12, 2018, 11:23:44 AM »

When attempting to load a large file (72MB) we received the following:
APK449S INDEX FIELDS REFERENCE OUTSIDE OF THE RECORD, FIELD# 6 INPUT RECORD# 1380465.

We are able to copy the file to NOTEPAD but with it being so large, its like finding a needle in a haystack where the bad record is.  Of course the 88 message doesn't show you what the exact line is that's causing the issue.  It gives the FIELD # which allows you to narrow down which index it is but its nearly impossible, even with specifying then index name, to find the bad record with it being so large.  Is there a way to somehow determine where the RECORD# is on the data file?  We've load over 200 files to this application and have had only 3 that have had issues.  The other 2 had the same issue but on different field names.

Appreciate any help.

86

Report Indexing / Re: POSTING DATE ISSUE

« on: October 31, 2018, 05:40:08 AM »

Finding the date in the same column else where on the file is a possibility...These dataset files are huge.....We decided just to manually update the default Posting Date field on the APP and load each file one at a time with the matching date on each file...These are one time loads to get old data onto CMOD..Once they are all loaded (approx. 45 or so) then we're done...Could probably get them all loaded in the time it would take to 'possibly' get something coded to work...Just was  asking to see if I was missing something simple to do..Thanks Greg for the input!!!!  Take care....Dave

87

Report Indexing / POSTING DATE ISSUE

« on: October 30, 2018, 05:37:35 AM »

we have an old mainframe report we are attempting to load to CMOD9.5 using an ACIF indexer..Appoxed 45 versions...We've respun the data to a mainframe dataset...We need to capture the date on the report.  Unfortunately its not on EVERY page of the report and the pages it is on it can move up and down lines...It is on the first page in this format (February 28, 2010) ...Is there a way to only look on the first page to get the date?  in the past I've had the scenario where the date is ONLY on the first page and I've set up a separate trigger to capture it and by removing the small 't' on the application definition...Tried doing that with this report going off of PAGE   1 as the trigger....Unfortunately, with this report other page 1's don't have the date on it so it fails..How can I force it to only look on the first page for the date?  There's no other fixed data on the page that's unique to only the first page to go off of for the date...These files are huge so we can't even manually add something ourselves to the first page..Goes to BROWSE SUBSTITUDED...Only other option is to manually update the DEFAULT value on the Application definition for POSTING date...

88

Report Indexing / Re: Break=YES vs Break=NO

« on: October 15, 2018, 05:31:14 AM »

Thanks Justin!....Your explanation does clarify things...This particular application is quite large....We questioned them prior on whether it was a need for so many indexes and they indicated they use all of them for searching in order to get to the exact information they need...As always, thanks for the info!...Take care....Dave

89

Report Indexing / Break=YES vs Break=NO

« on: October 09, 2018, 02:44:51 AM »

We have a report where the application has 26 (yes 26) indexes.  This is a text report.  When we run it through the Report Wizard it sets all the indexes to BREAK=YES.  We have many reports that are generated from the mainframe and sent to CMOD.  When these reports were initially converted to CMOD years ago, we've noticed, on their indexing, some fields are set to BREAK=YES while others are set to BREAK=NO...We know there has to be a rational for doing this but never really understood what that is.  Looking for any explanation....;-)

90

Report Indexing / Re: Indexing issues

« on: September 26, 2018, 07:55:18 AM »

Justin, I found my issue...The data had a lead page that wasn't a page with any indexing fields. Its only at the top of the file.....When I ran things through the wizard initially, I used the channel 1 for Trigger one from that lead page.  I then attempted to create my second trigger used for indexing the 19 fields from the second page which was based off of Trigger 1..With that lead page only being found once, it never found my second trigger again...Which goes back to your initial response indicating the trigger was ambiguous..;-)...The only thing needed off the first page was the date...So what I did was use the 1 on page 2 as my TRIGGER 1 and then from there, went down and got and found my second trigger and did a record range because it can fall anywhere between line 1 and 6 from the top of page...I was then able to capture my fields based off of trigger 2...For the date, I created a THIRD trigger, based off of Trigger 1 (going negative 18 lines) to find "for Date:" on the first page...Then went from there to get the actual date format for the fields...Hope this all makes sense!!!...As soon as you mention the ambiguous trigger it made me look closer at the trigger I was using for my indexing fields...Something clicked in my head to try and start everything from the second page and not the first!!  Appreciate the help to kick start my brain!!! take care

FYI- Ive attached a same of the first 2 pages of the file...

Dave