On Tue, 29 Apr 2014 09:20:04 -0500, Dale R. Smith <[email protected]> wrote:
>On Mon, 28 Apr 2014 09:24:23 -0500, Scott Barry <[email protected]> wrote: > >>Appears that CA JMR (output archival) has an architecture challenge with a >>shared JES environment and sites slowing migrating LPARs to z/OS V2R1 - that >>is parsing the SYSTEM from the JES Log for a batch-job archival is basically >>either environment, not both. With the JES log text-format change (i.e., >>long JES class names) and the location of the SYSTEM identification, archived >>output has a corrupted SYSTEM column and as was explained to a client we >>support, "that's all we can provide." Also, a search of the CA SUPPORT >>ONLINE system does not reveal any heads-up for impacted clients. >> >>So, JMR sites with co-existing z/OS environments (V1R13 & V2R1 for example) >>will likely see this information corruption for archived batch jobs during >>the phased z/OS V2R1 migration period. >> >>Scott Barry >>SBBWorks, Inc. > >Is the JES2 text format change a result of having long JES2 Job Classes >enabled or just from running JES2 for z/OS 2.1 without it being enabled? > >-- >Dale R. Smith > It's a JES log text-format change -- the offset to the SYSTEM information is different and the CA JMR software architecture requires that you tell it the exact position with a parameter SYSIODF, not considering the possible mixed-OS environment having different offset-locations -- why it's not a "scan to the next non-blank field" is beyond me. I for one do use the SORT primary command to re-order the job-list summary -- well, that's a NOOP until all LPARs are up on V2R1 for at least now. And hopefully someone will see the light - I could not even find a CA SUPPORT ONLINE KB reference about the condition either. Scott Barry SBBWorks, Inc. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
