Discussion:
AOXVTM module
(too old to reply)
Anne Crabtree
2018-01-09 18:42:30 UTC
Permalink
Raw Message
I’m having trouble getting Coaxial Printer Support fmid in z/OS V2R2 (yes, we still need it). I did the BUILDMCS from my z/OS V2R1 but the RECEIVE fails because AOXVTM module is not in AOP.AAOPMOD1 library. Any chance anyone has that module? (According to my notes I copied it from z/OS V1R13 to z/OS V2R1 this same way but that module is only in SYS1.LINKLIB for z/OS V2R1 not AOP.AAOPMOD1)!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2018-01-09 21:22:29 UTC
Permalink
Raw Message
Even if out of service, I think you would need to contact IBM for any proprietary modules

Do you still have the module you copied from z/OS V1.13? Could you copy IEFBR14 to your library with that name? Do you know what it does?



Lizette


> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
> Behalf Of Anne Crabtree
> Sent: Tuesday, January 09, 2018 11:44 AM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: AOXVTM module
>
> I’m having trouble getting Coaxial Printer Support fmid in z/OS V2R2 (yes, we
> still need it). I did the BUILDMCS from my z/OS V2R1 but the RECEIVE fails
> because AOXVTM module is not in AOP.AAOPMOD1 library. Any chance anyone has
> that module? (According to my notes I copied it from z/OS V1R13 to z/OS V2R1
> this same way but that module is only in SYS1.LINKLIB for z/OS V2R1 not
> AOP.AAOPMOD1)!
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Crabtree, Anne D
2018-01-10 12:08:09 UTC
Permalink
Raw Message
I do not have the volumes from 1.13, unfortunately. IBM has pretty much told me what I've already done... copied the LINKLIB module from V2R1 to V2R2 but AOPOUTD goes done mysteriously and we have to recycle infoprint. I am unable to find any messages to help determine why but I suspect the copy I can't find for the distribution library AOP.AAOPMOD1 is the problem. I was hoping someone had that distribution copy they could share with me...

Anne D. Crabtree
System Programmer
WV Office of Technology Data Center
1900 Kanawha Blvd East
Bldg 6, Room B-110
Charleston, WV 25305
(304)957-8292
(304)558-1441 fax
Work Hours: 7AM-3PM EST

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Tuesday, January 09, 2018 4:25 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: AOXVTM module

Even if out of service, I think you would need to contact IBM for any proprietary modules

Do you still have the module you copied from z/OS V1.13? Could you copy IEFBR14 to your library with that name? Do you know what it does?



Lizette


> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Anne Crabtree
> Sent: Tuesday, January 09, 2018 11:44 AM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: AOXVTM module
>
> I’m having trouble getting Coaxial Printer Support fmid in z/OS V2R2
> (yes, we still need it). I did the BUILDMCS from my z/OS V2R1 but the
> RECEIVE fails because AOXVTM module is not in AOP.AAOPMOD1 library.
> Any chance anyone has that module? (According to my notes I copied it
> from z/OS V1R13 to z/OS V2R1 this same way but that module is only in
> SYS1.LINKLIB for z/OS V2R1 not AOP.AAOPMOD1)!
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2018-01-10 12:39:45 UTC
Permalink
Raw Message
Maybe part of the SMPE install process deletes your module? Search
the jobs for the module name?

On Wed, Jan 10, 2018 at 6:09 AM, Crabtree, Anne D
<***@wv.gov> wrote:
> I do not have the volumes from 1.13, unfortunately. IBM has pretty much told me what I've already done... copied the LINKLIB module from V2R1 to V2R2 but AOPOUTD goes done mysteriously and we have to recycle infoprint. I am unable to find any messages to help determine why but I suspect the copy I can't find for the distribution library AOP.AAOPMOD1 is the problem. I was hoping someone had that distribution copy they could share with me...
>
> Anne D. Crabtree
> System Programmer
> WV Office of Technology Data Center
> 1900 Kanawha Blvd East
> Bldg 6, Room B-110
> Charleston, WV 25305
> (304)957-8292
> (304)558-1441 fax
> Work Hours: 7AM-3PM EST
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
> Sent: Tuesday, January 09, 2018 4:25 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Re: AOXVTM module
>
> Even if out of service, I think you would need to contact IBM for any proprietary modules
>
> Do you still have the module you copied from z/OS V1.13? Could you copy IEFBR14 to your library with that name? Do you know what it does?
>
>
>
> Lizette
>
>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
>> On Behalf Of Anne Crabtree
>> Sent: Tuesday, January 09, 2018 11:44 AM
>> To: IBM-***@LISTSERV.UA.EDU
>> Subject: AOXVTM module
>>
>> I’m having trouble getting Coaxial Printer Support fmid in z/OS V2R2
>> (yes, we still need it). I did the BUILDMCS from my z/OS V2R1 but the
>> RECEIVE fails because AOXVTM module is not in AOP.AAOPMOD1 library.
>> Any chance anyone has that module? (According to my notes I copied it
>> from z/OS V1R13 to z/OS V2R1 this same way but that module is only in
>> SYS1.LINKLIB for z/OS V2R1 not AOP.AAOPMOD1)!
>>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
i***@FOXMAIL.COM
2018-01-10 12:28:21 UTC
Permalink
Raw Message
Hi all

Could you tell us how to compare load modules ? but we don't care about ' Load module link date and time'.

Thanks a lot!

Jason Cai



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2018-01-10 18:20:57 UTC
Permalink
Raw Message
It depends on what you are looking for the compare and at what level.

What tools do you have

ISPF 3.13?

COMPAREX from Compuware

Probably others.

Lizette


> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
> Behalf Of ***@FOXMAIL.COM
> Sent: Wednesday, January 10, 2018 5:29 AM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Comparing load modules
>
>
> Hi all
>
> Could you tell us how to compare load modules ? but we don't care about '
> Load module link date and time'.
>
> Thanks a lot!
>
> Jason Cai
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-01-10 18:30:23 UTC
Permalink
Raw Message
Yes, but it's not for the faint of heart, and it might go wrong in ways that I haven't thought of. If the two load modules are not of the same size, then they're not equal. Otherwise, obtain a zeroed storage area (loadbuf) large enough to hold one, and a second storage area (comparebuf) of the same size. Do a directed load of the first, copy it, then load the second and compare.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of ***@foxmail.com <***@FOXMAIL.COM>
Sent: Wednesday, January 10, 2018 7:29 AM
To: IBM-***@listserv.ua.edu
Subject: Comparing load modules


Hi all

Could you tell us how to compare load modules ? but we don't care about ' Load module link date and time'.

Thanks a lot!

Jason Cai



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2018-01-10 20:11:02 UTC
Permalink
Raw Message
Whether differently-sized modules are inequal cannot be determined from
size alone when measured on disk (at least) for the reasons I posted
earlier. The same is true of record-based, LOAD-based, and even Binder
API-based binary compares.

Comparing LOADed modules is also not reliable in the general case for
somewhat different reasons that I mentioned in the same post. In
addition to those reasons, it occured to me that different ordering can
cause different amounts of storage to be consumed to maintain alignment
boundaries (and the owner of the Binder confirms that).

(This is *way* harder than it looks at first glance.)

Seymour J Metz wrote:
> Yes, but it's not for the faint of heart, and it might go wrong in ways that I haven't thought of. If the two load modules are not of the same size, then they're not equal. Otherwise, obtain a zeroed storage area (loadbuf) large enough to hold one, and a second storage area (comparebuf) of the same size. Do a directed load of the first, copy it, then load the second and compare.
<snip>
--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-01-10 20:21:31 UTC
Permalink
Raw Message
I'm talking about the size field in the directory, not the size of the memory.

There's a reason that I wrote "but it's not for the faint of heart, and it might go wrong in ways that I haven't thought of" ;-)


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of John Eells <***@US.IBM.COM>
Sent: Wednesday, January 10, 2018 3:12 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Comparing load modules

Whether differently-sized modules are inequal cannot be determined from
size alone when measured on disk (at least) for the reasons I posted
earlier. The same is true of record-based, LOAD-based, and even Binder
API-based binary compares.

Comparing LOADed modules is also not reliable in the general case for
somewhat different reasons that I mentioned in the same post. In
addition to those reasons, it occured to me that different ordering can
cause different amounts of storage to be consumed to maintain alignment
boundaries (and the owner of the Binder confirms that).

(This is *way* harder than it looks at first glance.)

Seymour J Metz wrote:
> Yes, but it's not for the faint of heart, and it might go wrong in ways that I haven't thought of. If the two load modules are not of the same size, then they're not equal. Otherwise, obtain a zeroed storage area (loadbuf) large enough to hold one, and a second storage area (comparebuf) of the same size. Do a directed load of the first, copy it, then load the second and compare.
<snip>
--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gibney, Dave
2018-01-10 20:31:56 UTC
Permalink
Raw Message
I use this PROC, several grains of salt and much IEAEYEBALL

//LOADCMPR PROC OLDLIB=,NEWLIB=
//IEBGEN1 EXEC PGM=IEBGENER,REGION=1M,TIME=10
//SYSPRINT DD DUMMY,SYSOUT=*
//SYSIN DD DUMMY
//SYSUT2 DD DSN=&&ZAPIN,DISP=(,PASS),
// SPACE=(80,(1,1)),RECFM=FB
//IEBGEN2 EXEC PGM=IEBGENER,REGION=1M,TIME=10
//SYSPRINT DD DUMMY,SYSOUT=*
//SYSIN DD DUMMY
//SYSUT2 DD DSN=&&AMBIN,DISP=(,PASS),
// SPACE=(80,(1,1)),RECFM=FB
//AMBLIST EXEC PGM=AMBLIST,REGION=5M
//SYSPRINT DD DSN=&&DT1,SPACE=(CYL,(1,1)),
// DISP=(NEW,PASS),LRECL=133,RECFM=FBA
//LOADLIB DD DSN=&OLDLIB,DISP=SHR
//SYSIN DD DSN=&&AMBIN,DISP=(OLD,PASS)
//ZAPPING EXEC PGM=AMASPZAP,REGION=5M
//SYSPRINT DD DSN=&&DT1,SPACE=(CYL,(1,1)),
// DISP=(MOD,PASS),LRECL=133,RECFM=FBA
//SYSLIB DD DSN=&OLDLIB,DISP=SHR
//SYSIN DD DSN=&&ZAPIN,DISP=(OLD,PASS)
//AMBLIST2 EXEC PGM=AMBLIST,REGION=5M
//SYSPRINT DD DSN=&&DT2,SPACE=(CYL,(1,1)),
// DISP=(NEW,PASS),LRECL=133,RECFM=FBA
//LOADLIB DD DSN=&NEWLIB,DISP=SHR
//SYSIN DD DSN=&&AMBIN,DISP=(OLD,PASS)
//ZAPPING2 EXEC PGM=AMASPZAP,REGION=5M
//SYSPRINT DD DSN=&&DT2,SPACE=(CYL,(1,1)),
// DISP=(MOD,PASS),LRECL=133,RECFM=FBA
//SYSLIB DD DSN=&NEWLIB,DISP=SHARE
//SYSIN DD DSN=&&ZAPIN,DISP=SHR
//SUPERC EXEC PGM=ISRSUPC,TIME=1439,
// PARM=(DELTAL,LINECMP,
// '',
// '')
//OLDDD DD DSN=&&DT1,DISP=(OLD,PASS)
//NEWDD DD DSN=&&DT2,DISP=(OLD,PASS)
//OUTDD DD SYSOUT=*
//SYSIN DD DSN=GIBNEY.PROCLIB(CMPCOLM),DISP=SHR
//IEBGENE1 EXEC PGM=IEBGENER,REGION=1M,TIME=10
//SYSPRINT DD DUMMY,SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DSN=&&DT1,DISP=(OLD,PASS)
//SYSUT2 DD SYSOUT=*
//IEBGENE2 EXEC PGM=IEBGENER,REGION=1M,TIME=10
//SYSPRINT DD DUMMY,SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DSN=&&DT2,DISP=(OLD,PASS)
//SYSUT2 DD SYSOUT=*

//COMPARE EXEC LOADCMPR,
// NEWLIB='GIBNEY.LOAD',
// OLDLIB='SYS1.VTAMLIB.WSU'
//IEBGEN1.SYSUT1 DD *
DUMPT USSTAZ FRED
//IEBGEN2.SYSUT1 DD *
LISTIDR OUTPUT=ALL,DDN=LOADLIB,TITLE=('IDR',50),MEMBER=USSTAZ
LISTLOAD OUTPUT=BOTH,DDN=LOADLIB,TITLE=('LOAD',50),MEMBER=USSTAZ

I wouldn't even attempt this at the scale the OP was proposing. Like others, I'd look at a fresh install and migration.


> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Seymour J Metz
> Sent: Wednesday, January 10, 2018 12:23 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Re: Comparing load modules
>
> I'm talking about the size field in the directory, not the size of the memory.
>
> There's a reason that I wrote "but it's not for the faint of heart, and it might
> go wrong in ways that I haven't thought of" ;-)
>
>
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-
> 7Esmetz3&d=DwIFAw&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=AO_KA3LFia469X_npaZWx8FkNg
> DDiC3ACzHXhSXPzOo&s=qkK2P8kGzBiQJvJic4ZSpYVsmL9zWwclHuKhn7z8SSE
> &e=
>
> ________________________________________
> From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf
> of John Eells <***@US.IBM.COM>
> Sent: Wednesday, January 10, 2018 3:12 PM
> To: IBM-***@listserv.ua.edu
> Subject: Re: Comparing load modules
>
> Whether differently-sized modules are inequal cannot be determined from
> size alone when measured on disk (at least) for the reasons I posted earlier.
> The same is true of record-based, LOAD-based, and even Binder API-based
> binary compares.
>
> Comparing LOADed modules is also not reliable in the general case for
> somewhat different reasons that I mentioned in the same post. In addition to
> those reasons, it occured to me that different ordering can cause different
> amounts of storage to be consumed to maintain alignment boundaries (and
> the owner of the Binder confirms that).
>
> (This is *way* harder than it looks at first glance.)
>
> Seymour J Metz wrote:
> > Yes, but it's not for the faint of heart, and it might go wrong in ways that I
> haven't thought of. If the two load modules are not of the same size, then
> they're not equal. Otherwise, obtain a zeroed storage area (loadbuf) large
> enough to hold one, and a second storage area (comparebuf) of the same
> size. Do a directed load of the first, copy it, then load the second and
> compare.
> <snip>
> --
> John Eells
> IBM Poughkeepsie
> ***@us.ibm.com
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> ***@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2018-01-10 20:54:19 UTC
Permalink
Raw Message
Seymour J Metz wrote:
> the size field in the directory

...might well be inequal as well if the module length differs due to
alignment requirements, for example.

--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2018-01-10 12:48:12 UTC
Permalink
Raw Message
Jason Cai wrote:

> Could you tell us how to compare load modules ? but we don't care about ' Load module link date and time'.

It is not easy, simply because of blocksize and different TTRs, but can be done.

One or many load modules? (Oh, one loadmod can contains 1 or many sections.)

Do you want to do a binary or hex comparision?
Do you want to compare by bits, bytes, lines or words (halfword, fullword)?
Do you just want to compare file sizes or load module attributes?
Foreground or background method?

Or, please tell us what you are trying to see or solve?

PS: I would recommend using AMBLIST utility with LISTLOAD OUTPUT=MODLIST and then use SuperC to compare the outputs.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
i***@FOXMAIL.COM
2018-01-10 13:00:34 UTC
Permalink
Raw Message
Because oure SMPE was deleted,we want to re- install zos /subsystem software and apply all PTFs to rebuild a new SMPE and new load moduls.

After that,we we want to compare all new load moduls with our current load moduls to make sure they are all same.

Excepting Load module link date and time,do we need compare everything?

Backgroup method is better.

Thanks a lot!




> Could you tell us how to compare load modules ? but we don't care about ' Load module link date and time'.

It is not easy, simply because of blocksize and different TTRs, but can be done.

One or many load modules? (Oh, one loadmod can contains 1 or many sections.)

Do you want to do a binary or hex comparision?
Do you want to compare by bits, bytes, lines or words (halfword, fullword)?
Do you just want to compare file sizes or load module attributes?
Foreground or background method?

Or, please tell us what you are trying to see or solve?

PS: I would recommend using AMBLIST utility with LISTLOAD OUTPUT=MODLIST and then use SuperC to compare the outputs.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
i***@FOXMAIL.COM
2018-01-10 13:33:07 UTC
Permalink
Raw Message
hi Elardus Engelbrecht

>It is not easy, simply because of blocksize and different TTRs, but can be done.

>One or many load modules? (Oh, one loadmod can contains 1 or many sections.)

many load modules

>Do you want to do a binary or hex comparision?

hex comparision

>Do you want to compare by bits, bytes, lines or words (halfword, fullword)?

compare by bytes

>Do you just want to compare file sizes or load module attributes?

yes

> Foreground or background method?

background method

>Or, please tell us what you are trying to see or solve?

rebuild a new smpe env

> PS: I would recommend using AMBLIST utility with LISTLOAD OUTPUT=MODLIST and then use SuperC to compare the outputs.

Could you give sample to do it?

Thanks a lot!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2018-01-10 14:19:57 UTC
Permalink
Raw Message
This sounds as though it should be easy, but it is in reality
deceptively difficult. It would take quite a bit of work to be certain
that everything is really the same.

The block size and starting location on a track determine how much space
is used for two "identical" copies of a particular load module. Both
that and the order in which members are loaded will change the directory
content for both PDS and PDSE, and also affect the number and content of
text records and the amount of space used in a PDS. Additionally, the
number and content of at least some non-text records (control records,
at a minimum) will likely differ, at least for PDSs. This applies to
both copied (with COPYMOD) and bound modules. These challenges make
disk-to-disk compares difficult at best.

The order in which CSECTs are bound will likely cause a number of both
AMBLIST and binary compares, no matter how performed, to show different
outputs for "identical" copies of modules (really, those with the same
bits and pieces of code at the same levels, but bound in different
orders). This will potentially affect the content of any module
represented by an LMOD entry that has more than one MOD and has no LKED
ORDER statements in the LMOD entry. Even those with ORDER statements
can have different orders when all of the CSECTs in all of the MODs are
not named on the ORDER statements. (Also, multi-CSECT MODs can make
this more time-consuming to determine.)

Unless you have the same starting point as the original system, and
install same PTFs that were installed on the original system on the
rebuilt system in the same number of APPLY steps run in the same order,
the probability that all the "identical" copies of modules that are at
the same service level will actually appear to be identical is very low.

Add in some ERROR HOLDs, GEXT, etc., and things quickly go from bad
worse (in this respect, at least).

From a practical standpoint, if you cannot find backups of the CSI data
sets that are known to correspond with the code levels you are running,
my suggestion is to rebuild, put on current service, and treat the
result like any other maintenance upgrade from testing and migration
points of view. It will almost certainly take far less time, and if you
put recommended service on the result could well be better.

--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2018-01-10 14:29:09 UTC
Permalink
Raw Message
Correction: I forgot that SMP/E multitasks binder steps until
immediately after hitting "send." (Isn't that always the way?) So,
even trying to build up an identical system for which binary compares
would work is perhaps nearly impossible in the first place, and it would
be very, very difficult at best.

John Eells wrote:
> This sounds as though it should be easy, but it is in reality
> deceptively difficult. It would take quite a bit of work to be certain
> that everything is really the same.
>
> The block size and starting location on a track determine how much space
> is used for two "identical" copies of a particular load module. Both
> that and the order in which members are loaded will change the directory
> content for both PDS and PDSE, and also affect the number and content of
> text records and the amount of space used in a PDS. Additionally, the
> number and content of at least some non-text records (control records,
> at a minimum) will likely differ, at least for PDSs. This applies to
> both copied (with COPYMOD) and bound modules. These challenges make
> disk-to-disk compares difficult at best.
>
> The order in which CSECTs are bound will likely cause a number of both
> AMBLIST and binary compares, no matter how performed, to show different
> outputs for "identical" copies of modules (really, those with the same
> bits and pieces of code at the same levels, but bound in different
> orders). This will potentially affect the content of any module
> represented by an LMOD entry that has more than one MOD and has no LKED
> ORDER statements in the LMOD entry. Even those with ORDER statements
> can have different orders when all of the CSECTs in all of the MODs are
> not named on the ORDER statements. (Also, multi-CSECT MODs can make
> this more time-consuming to determine.)
>
> Unless you have the same starting point as the original system, and
> install same PTFs that were installed on the original system on the
> rebuilt system in the same number of APPLY steps run in the same order,
> the probability that all the "identical" copies of modules that are at
> the same service level will actually appear to be identical is very low.
>
> Add in some ERROR HOLDs, GEXT, etc., and things quickly go from bad
> worse (in this respect, at least).
>
> From a practical standpoint, if you cannot find backups of the CSI data
> sets that are known to correspond with the code levels you are running,
> my suggestion is to rebuild, put on current service, and treat the
> result like any other maintenance upgrade from testing and migration
> points of view. It will almost certainly take far less time, and if you
> put recommended service on the result could well be better.
>


--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2018-01-10 20:14:28 UTC
Permalink
Raw Message
John Eells wrote:
> Correction: I forgot that SMP/E multitasks binder steps until
> immediately after hitting "send." (Isn't that always the way?) So,
> even trying to build up an identical system for which binary compares
> would work is perhaps nearly impossible in the first place, and it would
> be very, very difficult at best.
<snip>

OK, a correction to the correction (sorry, all). Although the order of
binds in an APPLY step is not necessarily predictable, any particular
load module (or program object) should be bound only once in a single
APPLY step. So this does not add another variant--even though there are
enough other variants to render this comparison quite hard, if not
pretty close to infeasible. (Thanks for the clarification, KQ!)

--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-01-10 13:27:32 UTC
Permalink
Raw Message
On Tue, 9 Jan 2018 12:43:37 -0600, Anne Crabtree wrote:

>I did the BUILDMCS from my z/OS V2R1 but the RECEIVE fails because AOXVTM module is not in AOP.AAOPMOD1 library.

Was the function accepted on your V2R1 system before you ran the BUILDMCS?

What do the BUILDMCS reports show?

--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Crabtree, Anne D
2018-01-10 13:50:35 UTC
Permalink
Raw Message
No, function was only APPLY'd on my z/OS V2R1 system.

BUILDMCS creates this file

++FUNCTION(HPRT200) DESC(Coaxial Printer Support) REWORK(2018010)
/******************************************************************/
/******************************************************************/
/*** THIS MCS FOR FUNCTION HPRT200 WAS CREATED BY THE BUILDMCS ***/
/*** COMMAND ON 2018010 FROM TARGET ZONE Z21T100 ***/
/******************************************************************/
/******************************************************************/ .
++VER(Z038) DELETE(HPRT100) PRE(HOPI705) REQ(HBB7707) SUP(AA15333,
AA21245,AA21665,AA24011,AA24576,HPRT100,UA24854,UA34584,UA38382,UA40012,
UA40893).
++MOD(AOXVTM) DISTLIB(AAOPMOD1) FROMDS(DSN(MCAT.AOP.AAOPMOD1) NUMBER(1))
RMID(UA40893) LMOD(AOXVTM) .
++SAMP(AOXDDEFP) DISTLIB(ASAMPLIB) FROMDS(DSN(MCAT.SYS1.ASAMPLIB)
NUMBER(2)) SYSLIB(SAMPLIB).
++JCLIN CALLLIBS.
//COPY EXEC PGM=IEBCOPY
//SYSIN DD *
COPY OUTDD=SAMPLIB,INDD=ASAMPLIB
//LINK0001 EXEC PGM=IEWBLINK,PARM=('OPTIONS(GENOPTS)')
//GENOPTS DD *
RENT,AMODE=31,RMODE=24
//SYSLMOD DD DSN=LINKLIB
//SYSLIN DD *
ENTRY AOXVTM
INCLUDE AAOPMOD1(AOXVTM) FMID=HPRT200
NAME AOXVTM RC=0

When I try to RECEIVE it:
IEB1135I IEBCOPY FMID HDZ2210 SERVICE LEVEL UA83949 DATED 20170202 DFSMS 02.0
IEB1035I SYSMPREC SMP 08:34:57 WED 10 JAN 2018 PARM='CMWA=256K,SPCLCMOD,WO
COPYMOD OUTDD=SMPTLIB,INDD=SMP00001 SMPTLIB - 1 HPRT200
S M=((AOXVTM,,R)) HPRT200
IEB190I MAXIMUM BLOCK SIZE IS 32760, MINIMUM BLOCK SIZE IS 1024
IEB1013I COPYING FROM PDS INDD=SMP00001 VOL=Z22DLB DSN=AOP.AAOPMOD1
IEB1014I TO PDS OUTDD=SMPTLIB VOL=Z22SMP DSN=SMPE.ZOSR22.HPRT200.F1
IEB1160I OUTPUT DATASET RECFM/LRECL/BLKSIZE COPIED FROM INPUT DATASET
IEB159I NO MEMBERS COPIED FROM INPUT DATA SET REFERENCED BY SMP00001
IEB177I AOXVTM WAS SELECTED BUT NOT FOUND IN ANY INPUT DATA SET
IEB144I THERE ARE 1955 UNUSED TRACKS IN OUTPUT DATA SET REFERENCED BY SMPTLIB
IEB151I JOB HAS TERMINATED WITH ERROR(S)
IEB147I END OF JOB - 4 WAS HIGHEST SEVERITY CODE



Anne D. Crabtree
System Programmer
WV Office of Technology Data Center
1900 Kanawha Blvd East
Bldg 6, Room B-110
Charleston, WV 25305
(304)957-8292
(304)558-1441 fax
Work Hours: 7AM-3PM EST

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tom Marchant
Sent: Wednesday, January 10, 2018 8:29 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: AOXVTM module

On Tue, 9 Jan 2018 12:43:37 -0600, Anne Crabtree wrote:

>I did the BUILDMCS from my z/OS V2R1 but the RECEIVE fails because AOXVTM module is not in AOP.AAOPMOD1 library.

Was the function accepted on your V2R1 system before you ran the BUILDMCS?

What do the BUILDMCS reports show?

--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2018-01-10 14:42:56 UTC
Permalink
Raw Message
Lots of stuff is squirreled away here, and it so happens that we have a
copy of the JCLIN for that FMID on our local system. Here it is:

//STEP1 EXEC PGM=IEWL,
// PARM='LIST,LET,XREF,RENT,AMODE=31,RMODE=24',
// REGION=512K
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(4,1))
//SYSPRINT DD SYSOUT=*
//SYSLMOD DD DSN=SYS1.LINKLIB,DISP=SHR
//AAOPMOD1 DD DSN=AOP.AAOPMOD1,DISP=SHR
//*
//SYSLIN DD *
INCLUDE AAOPMOD1(AOXVTM)
ENTRY AOXVTM
NAME AOXVTM(R) RC=0
/*

I do *not* have the entire product, its SMPMCS, or its service history,
so some investigation is needed.

You can run LIST LMOD(AOXVTM) XREF against your target zone (Z21T100) to
confirm that you have an LMOD entry for AOXVTM and that it is still a
single-MOD LMOD. Also, this will confirm that there *is* a MOD entry
for it. Perhaps it was deleted by a later SYSMOD and is not simply
"just missing." Perhaps we can figure out where to go from there.

--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Crabtree, Anne D
2018-01-10 15:21:16 UTC
Permalink
Raw Message
Thank you everybody for forcing me to think!
After I went back to z/OS V2R1 and ACCEPT’d HPRT200, the process worked fine!


Anne D. Crabtree
System Programmer
WV Office of Technology Data Center
1900 Kanawha Blvd East
Bldg 6, Room B-110
Charleston, WV 25305
(304)957-8292
(304)558-1441 fax
Work Hours: 7AM-3PM EST
NFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Crabtree, Anne D
2018-01-10 14:40:01 UTC
Permalink
Raw Message
Duh. A lightbulb just came on and I realize when I copied from z/OS V1R13, the function was already ACCEPT'd but had only been APPLY'd in z/OS V2R1. Starting over!
Thank you for getting me thinking correctly!

Anne D. Crabtree
System Programmer
WV Office of Technology Data Center
1900 Kanawha Blvd East
Bldg 6, Room B-110
Charleston, WV 25305
(304)957-8292
(304)558-1441 fax
Work Hours: 7AM-3PM EST

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tom Marchant
Sent: Wednesday, January 10, 2018 8:29 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: AOXVTM module

On Tue, 9 Jan 2018 12:43:37 -0600, Anne Crabtree wrote:

>I did the BUILDMCS from my z/OS V2R1 but the RECEIVE fails because AOXVTM module is not in AOP.AAOPMOD1 library.

Was the function accepted on your V2R1 system before you ran the BUILDMCS?

What do the BUILDMCS reports show?

--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-01-10 13:55:28 UTC
Permalink
Raw Message
On Wed, 10 Jan 2018 21:01:40 +0800, ***@foxmail.com wrote:

> Because oure SMPE was deleted,

And you have no backups?

>we want to re- install zos /subsystem software and apply all PTFs to rebuild a new SMPE and new load moduls.

Sounds like a good plan

>After that,we we wantoto compare all new load moduls with our current load moduls to make sure they are all same.

I wouldn't do that. Instead, I'd create new target and distribution zones with more current maintenance, test it, and roll it into production using my normal procedures. Leave the old IPL volume around for a while in case of problems.

--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-01-10 20:29:45 UTC
Permalink
Raw Message
On Wed, 10 Jan 2018 15:12:17 -0500, John Eells wrote:

>Whether differently-sized modules are inequal cannot be determined from
>size alone when measured on disk (at least) for the reasons I posted
>earlier. The same is true of record-based, LOAD-based, and even Binder
>API-based binary compares.
>
>Comparing LOADed modules is also not reliable in the general case for
>somewhat different reasons that I mentioned in the same post. In
>addition to those reasons, it occured to me that different ordering can
>cause different amounts of storage to be consumed to maintain alignment
>boundaries (and the owner of the Binder confirms that).
>
Relink one with ORDER statements to match the other, then compare?
Oops! What about anonymous CSECTs?

>(This is *way* harder than it looks at first glance.)
>
Yup. And even IEBCOPY modifies the FAMS timestamp. As if that mattered.
(Am I supposed to know about FAMS timestamps?)

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-01-10 20:50:01 UTC
Permalink
Raw Message
On Wed, 10 Jan 2018 15:12:17 -0500, John Eells wrote:
>
>(This is *way* harder than it looks at first glance.)
>
That said, one of our developers once was delighted when the AMBLIST/SUPERC
technique revealed that one element has been assembled with an outdated SYSLIB.
But she had the advantage of a priori knowledge that the modules behaved
differently. Different displacements identified the perpetrator.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Doug
2018-01-10 20:57:40 UTC
Permalink
Raw Message
IBM file manager can if you have it.
Regards, Doug

.

On Jan 10, 2018, at 15:51, Paul Gilmartin <0000000433f07816-dmarc-***@LISTSERV.UA.EDU> wrote:

> On Wed, 10 Jan 2018 15:12:17 -0500, John Eells wrote:
>
> (This is *way* harder than it looks at first glance.)
>
That said, one of our developers once was delighted when the AMBLIST/SUPERC
technique revealed that one element has been assembled with an outdated SYSLIB.
But she had the advantage of a priori knowledge that the modules behaved
differently. Different displacements identified the perpetrator.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Kevin Corbett
2018-01-11 14:22:02 UTC
Permalink
Raw Message
File-AID/MVS has a Compare feature that will meet your requirements. And the compare can be run "online" or in batch. There are a number of Compare Criteria that can be used:

Use "S" to select member compare criteria:
S Module Name
_ Load Module Size
_ Entry Point
_ Link Attributes
_ Link Date

Use "S" to select CSECT compare criteria:
_ CSECT Name
_ CSECT Size
_ Language
_ CSECT Date
_ IDR ZAP Data
_ Text

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...