Author Topic: Multiple Apps associated with Single APP group issue  (Read 3069 times)

DDP021

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Multiple Apps associated with Single APP group issue
« on: September 25, 2014, 05:01:47 AM »
Hi...Wanted to pass on an issue we recently ran into...Most of our reports loaded via the mainframe to CMOD...We ran into an issue where we defined one application group and 5 associated apps back in June...The input datasets that created the reports were all allocated at LRECL of 133...Recently, they wanted to add 2 new applications..Since they were for  the same app and retention was the same, we just added them to the existing application group..The difference being their input datasets LRECL were 80 and 81...Everytime we attempt to load the data to CMOD, the mainframe job we run would abend with a condition code 016..The error indicated, - "INREC  field outside range"...After investigating, we found once we defined a new application group for each new application, the data loaded successfully for each...Even though we saw nothing associated on the application group regarding LRECL (that's setup on the application), it appears that once data was loaded to the original application group who's reports were 133, it didn't like anything else but 133 loaded to it..Apparently you can't mix Applications with different LRECLS using the same Application Group...Not sure if anyone else has run into this issue or not..Just wanted to give the FYI on what we found...

jeffs42885

  • Guest
Re: Multiple Apps associated with Single APP group issue
« Reply #1 on: September 25, 2014, 05:18:27 AM »
I did not notice this, nor did I ever see an issue doing this.

In my past assignment, we dealt with EBCIDIC files all with logical record lengths, and we had "mixed and mashed" app groups that contained RECL of 100, 200, 133, 150 etc..and I never noticed a problem. Current assignment is all ASCII based, and we are using a 1 AG to 1 APP relationship, so it shouldn't matter. But it's definitely a good thing to have in my back pocket.

DDP021

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Re: Multiple Apps associated with Single APP group issue
« Reply #2 on: September 25, 2014, 05:45:43 AM »
Ya...At first we thought it was the data the application was sending...Thought it was corrupt....Every other report they've setup used 133 except these two (that were using 80 and 81 LRECL)....Once we defined a new application group for each application, the data loaded successfully for both...The only thing it pointed to then was the application group...It seemed once data was loaded to it that was 133, nothing else could be loaded using it that wasn't 133...

jeffs42885

  • Guest
Re: Multiple Apps associated with Single APP group issue
« Reply #3 on: September 25, 2014, 06:33:43 AM »
That sounds extremely strange to me, perhaps a bug?

DDP021

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Re: Multiple Apps associated with Single APP group issue
« Reply #4 on: September 25, 2014, 06:54:41 AM »
Just some more background...These reports are all NODEX reports using the ACIF indexer...The data is sent to CMOD from the mainframe using a mainframe job...it is transferred using MVS download and ARSLOAD.....On the mainframe, we have a dataset that specifies the LRECL for each application (see below)...The mainframe job we submit abends with a condition code 016...We never received an 88 msg on CMOD....Not sure where the conflict is occurring...On the JCL we run to load the data, we specify the Application and Application group name...It's also using a PROC..


 SORT FIELDS=COPY       
 INREC FIELDS=(1:1,080) 


LWagner

  • Guest
Re: Multiple Apps associated with Single APP group issue
« Reply #5 on: November 21, 2014, 04:12:02 PM »
Resolved ?

Sounds like an application issue.  Record length is defined there, not in the app group.
Was the Indexer Information adapted to each of the shorter record length reports, which DO
have a record length definition ? Data positions can't be beyond record length.