| Newsgroups |
gmane.comp.emulators.hercules390.mvs |
| Message-ID |
<[email protected]> |
I'm glad that I learned (the hard way) the value of not modifying IBM's or any vendor's libraries. It certainly made upgrades and maintenance easier. I've spent a lot of time trolling through employers libraries attempting to separate vendor from employer code. Some of it many decades deep.Sent from my T-Mobile 4G LTE Device
-------- Original message --------From: "Joe Monk [email protected] [H390-MVS]" <[email protected]> Date: 9/27/19 9:42 PM (GMT-05:00) To: [email protected] Subject: Re: [H390-MVS] SXMACLIB
His test procedure works because he doesn't pollute sys1.maclib.This his test procedure will run unchanged on both mvs and z/os.JoeOn Fri, Sep 27, 2019, 20:38 [email protected] [H390-MVS] <[email protected]> wrote:
---In [email protected], <gerhardp@...> wrote :
>> That's not correct. I'm making the source
>> code and even the assembly JCL portable
>> between MVS/380 and z/OS. So long as
>> you follow the published rules, everything
>> works like magic.
> No; sane people will keep non-IBM stuff out of IBM libraries. It's
MVS/380 is published by Jujitsu, not IBM,
and Jujitsu thought it was easier to add
"LG" etc to SYS1.MACLIB than to
IFOX00, which is an internal implementation
decision.
> easier for others to concatenate another macro library ahead of
> SYS1.MACLIB.
No, no such dataset exists on z/OS, because
"LG" is part of ASMA90, so it is not part of the
concatenation or the JCL. I want such JCL to
work on MVS/380 unchanged, not have to be
updated to point to some non-standard
macro library.
> My typical test procedures have provisions for nine
> libraries, with SYS1.MACLIB the second, and all replaceable with
> symbolic parameters.
Your test procedures that don't exist on a
typical z/OS box. The "LG" instruction
exists on a typical z/OS box though. And
it appears on a typical MVS/380 box too.
Part of what makes MVS/380 such a great
development environment.
BFN. Paul.