Re: Determining required z/series hardware level - REVISED

[Peter Van Dyke]

Just wanted to add to my earlier post. The disassembler provided with the
Assembler Toolkit is now part of HLASM and shipped as load module ASMADOP
in SYS1.MIGLIB. Looks like this was done with APAR PQ27453 back in 1999!

Regards,
Peter Van Dyke
HCL Software


On Wed, 9 Dec 2020 at 10:54, Mike Hochee  wrote:

> Thanks all, yet again, for all the excellent ideas! These IBM- listservs
> are a truly fine resource. ('the power of many brains working!')  I will
> probably end up doing some flavor of opcode evaluation, and assumed, maybe
> erroneously, that opcode evaluation would be simpler/cleaner to implement
> than parsing or scanning source (which is available). I generally feel more
> comfortable working with machine/product outputs rather than the curveballs
> humans sometimes throw.
>
> Best,
> Mike
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Hochee
> Sent: Tuesday, December 8, 2020 5:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining required z/series hardware level - REVISED
>
> Warning! This is a fake (spoofed) message. DO NOT TRUST!
>
> Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'
>
> Hi,
>
> I'm looking for a utility/program which is capable of reading a z/OS
> executable, whether an lmod or program object, or unbound object code, and
> examining it for hardware/architecture level compatibility. I'm not
> specifically referring to the ARCLVL of on the SYSSTATE macro, although I
> know there is some correspondence, but rather to the set of unprivileged
> instructions introduced at a particular hardware architecture levels.
> Apologies in advance for any imprecise/inaccurate  terminology.
>
> For example, let's say I happen to know that the most recently introduced
> z/Series instruction used by a particular executable is the AHI
> instruction, then I would expect this utility/program to output 'G10',
> suggesting the minimum hardware architecture required to support execution.
>
> I understand things are not always black/white in this area and could be
> clouded by instruction facility requirements, etc..
>
> Thanks in advance for any suggestions, guidance.
>
> Mike
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Determining required z/series hardware level - REVISED

[Charles Mills]

There is always the approach of running the program. ABEND S0C1 indicates
that you need a newer box (or better programmers).

I suppose an arguably good corporate standard might be to require embedding
the required ARCH level in programs as a readable EBCDIC constant. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mike Hochee
Sent: Tuesday, December 8, 2020 6:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

Thanks all, yet again, for all the excellent ideas! These IBM- listservs are
a truly fine resource. ('the power of many brains working!')  I will
probably end up doing some flavor of opcode evaluation, and assumed, maybe
erroneously, that opcode evaluation would be simpler/cleaner to implement
than parsing or scanning source (which is available). I generally feel more
comfortable working with machine/product outputs rather than the curveballs
humans sometimes throw.  

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

Re: Determining required z/series hardware level - REVISED

[Mike Hochee]

Thanks all, yet again, for all the excellent ideas! These IBM- listservs are a 
truly fine resource. ('the power of many brains working!')  I will probably end 
up doing some flavor of opcode evaluation, and assumed, maybe erroneously, that 
opcode evaluation would be simpler/cleaner to implement than parsing or 
scanning source (which is available). I generally feel more comfortable working 
with machine/product outputs rather than the curveballs humans sometimes throw. 
 

Best, 
Mike   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Hochee
Sent: Tuesday, December 8, 2020 5:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

Warning! This is a fake (spoofed) message. DO NOT TRUST!

Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'

Hi,

I'm looking for a utility/program which is capable of reading a z/OS 
executable, whether an lmod or program object, or unbound object code, and 
examining it for hardware/architecture level compatibility. I'm not 
specifically referring to the ARCLVL of on the SYSSTATE macro, although I know 
there is some correspondence, but rather to the set of unprivileged 
instructions introduced at a particular hardware architecture levels. Apologies 
in advance for any imprecise/inaccurate  terminology.

For example, let's say I happen to know that the most recently introduced 
z/Series instruction used by a particular executable is the AHI instruction, 
then I would expect this utility/program to output 'G10', suggesting the 
minimum hardware architecture required to support execution.

I understand things are not always black/white in this area and could be 
clouded by instruction facility requirements, etc..

Thanks in advance for any suggestions, guidance.

Mike


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

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

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

Re: does anyone recall any details about MVS/XA?

[Paul Gilmartin]

On Wed, 9 Dec 2020 01:50:32 +, Jesse 1 Robinson wrote:

>We have downloaded ServerPac for years entirely from the network. No need for 
>tape.
> 
What would one use to access the network?

>
On Wed, 9 Dec 2020 02:12:11 +, Seymour J Metz wrote:
>
>AFAIK tape is no longer an option. There used to be a DVD option; I don't no 
>whether it is still available. The normal vehicle for product and service 
>these days is the Internet.
>
>The basic process is still the same; if you don't have a driver system, you 
>need to restore a starter system and you must have an IOCDS that supports it. 
>The CBPDO dialogs all run on the driver system and the new system.

>

>>>From:  Paul Gilmartin 
>Sent: Tuesday, December 8, 2020 8:41 PM
>
>What's the process today for a new site with no real tapes?
>
I mean a really, really new site.

-- gil

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

Re: does anyone recall any details about MVS/XA?

[Seymour J Metz]

AFAIK tape is no longer an option. There used to be a DVD option; I don't no 
whether it is still available. The normal vehicle for product and service these 
days is the Internet.

The basic process is still the same; if you don't have a driver system, you 
need to restore a starter system and you must have an IOCDS that supports it. 
The CBPDO dialogs all run on the driver system and the new system.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, December 8, 2020 8:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA?

On Wed, 9 Dec 2020 00:48:31 +, Seymour J Metz wrote:

>You needed an MVS driver system to install MVS/XA. Most customers already had 
>an existing MVS/SP system, and didn't need to order the starter system. IPO 
>and PSO were available later. Optional souce was available on tape. There was 
>no PTF optional source; if the module was hit by service, you had to rely on 
>the microfiche.
>
What's the process today for a new site with no real tapes?

-- gil

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

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

Re: does anyone recall any details about MVS/XA?

[Jesse 1 Robinson]

We have downloaded ServerPac for years entirely from the network. No need for 
tape.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Tuesday, December 8, 2020 5:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: does anyone recall any details about MVS/XA?

*** EXTERNAL EMAIL - Use caution when opening links or attachments ***

On Wed, 9 Dec 2020 00:48:31 +, Seymour J Metz wrote:

>You needed an MVS driver system to install MVS/XA. Most customers already had 
>an existing MVS/SP system, and didn't need to order the starter system. IPO 
>and PSO were available later. Optional souce was available on tape. There was 
>no PTF optional source; if the module was hit by service, you had to rely on 
>the microfiche.
>
What's the process today for a new site with no real tapes?

-- gil


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

Re: does anyone recall any details about MVS/XA?

[Paul Gilmartin]

On Wed, 9 Dec 2020 00:48:31 +, Seymour J Metz wrote:

>You needed an MVS driver system to install MVS/XA. Most customers already had 
>an existing MVS/SP system, and didn't need to order the starter system. IPO 
>and PSO were available later. Optional souce was available on tape. There was 
>no PTF optional source; if the module was hit by service, you had to rely on 
>the microfiche.
>
What's the process today for a new site with no real tapes?

-- gil

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

Re: does anyone recall any details about MVS/XA? [EXTERNAL]

[Joe Monk]

Yes, IPO used generate.

There was IPOUPDTE and IPOGEN.

http://www.computinghistory.org.uk/downloads/9653

Joe

On Tue, Dec 8, 2020 at 6:08 PM Seymour J Metz  wrote:

> GENERATE rebuilds the target datasets from the distribution data sets; you
> still need an MVS/SP system generation or MVSCP to define the I/O
> configuration. I don't recall IPO ever using GENERATE, but memory is the
> second thing to go.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Lennie Dymoke-Bradshaw [032fff1be9b4-dmarc-requ...@listserv.ua.edu]
> Sent: Tuesday, December 8, 2020 6:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]
>
> I ran these CBIPO installs in the early eighties. I am pretty sure it used
> SMP/E to perform the generation using the GENERATE command.
> I had an MVS/SP driving system of course. The first MVS/XA system I built
> was XA 2.1.2 I think.
>
> Lennie Dymoke-Bradshaw
> Consultant working on contract for BMC mainframe Services by RSM Partners
> ‘Dance like no one is watching. Encrypt like everyone is.’
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Pommier, Rex
> Sent: 08 December 2020 22:30
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]
>
> Paul,
>
> Thank you for that memory jog.  Yep, it was MVS/Express.  It was a
> stand-alone restore tape of MVS/XA (ours was 2.1.7) that once restored was
> an IPLable XA system - and reasonably current on maintenance.
>
> Fun time was going to a class for MVS newbies and using the MVS/express
> tape.  8 of us trying to restore stand-alone tapes on top of a VM 4381.
> Watching the tape turn ever-so-slowly trying to load MVS.
>
> So when we initially brought up XA 2.1.7, it was the express tape which
> was the starter system soon followed by a CBIPO tape to load down a more
> current set of software and yes, there was a SYSGEN in the middle of the
> CBIPO install process.
>
> Those are old, rusty memories.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Feller, Paul
> Sent: Tuesday, December 8, 2020 4:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]
>
> For those new to MVS there was the MVS/XA Express option.  You have to
> qualify to get it.  A shop I worked at a long time ago was a VSE shop that
> was going to convert to MVS and that is how we started off.  I believe the
> MVS/XA Express was a complete IPL system that IBM built based on your
> environment.  I think it was basically a restore and IPL type situation.
> After that I don't recall what had to be done.  It was a long (long) time
> ago so the memory is a little fuzzy.
>
>
>
> Thanks..
>
> Paul Feller
> GTS Mainframe Technical Support
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Mark Jacobs
> Sent: Tuesday, December 8, 2020 3:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]
>
> The *fun* memories of a POR before every time we tested MVS/XA and then
> another one when we went back to MVS/SP for production just returned.
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key -
> https://urldefense.proofpoint.com/v2/url?u=https-3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com&d=DwIFaQ&c=9g4MJkl2VjLjS6R4ei18BA&r=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc&m=KK1yXXNOBVuutibinfGrz7q-E8DxWAgMfozPwM_fdas&s=Aeq0PrNdOcRqdsiFkHkGJt4xsGO8Guev3vSwvmvSc-s&e=
>
> ‐‐‐ Original Message ‐‐‐
>
> On Tuesday, December 8th, 2020 at 4:18 PM, Farley, Peter x23353 <
> 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>
> > ISTR there was also a special version of VM/XA made available "early" so
> that customers could run both 24-bit MVS/SP and 31-bit MVS/XA on the same
> physical machine.
> >
> > Peter
> >
> > -Original Message-
> >
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf
> > Of Brian France
> >
> > Sent: Tuesday, December 8, 2020 4:11 PM
> >
> > To: IBM-MAIN@LISTSERV.UA.EDU
> >
> > Subject: Re: does anyone recall any details about MVS/XA?
> >
> > I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.
> >
> > SYSGEN I think was still needed for XA and maybe ESA.
> >
> > I'm not sure what you meant by Optional Source Materials. If by that you
> meant optional source code to install, I think they went the microsloth
> bloat ware option later...
> >
> > On 12/8/2020 4:00 PM, Joe Monk wrote:
> >
> > > i thought MVS/XA was CBIPO?
> > >
> > > Joe
> > >
> > > On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
> > >
> > > 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > > > Hi, all,
> > > >
> > > 

Re: Determining required z/series hardware level - REVISED

[Seymour J Metz]

There is certainly code that uses, e.g., STFLE, and checks the result.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mike Schwab [mike.a.sch...@gmail.com]
Sent: Tuesday, December 8, 2020 7:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

Is the facility to check for the facility bits often present in load
modules?  I. E. a certain opcode or SVC call?  Then hou could look at
the bits being checked.

On Tue, Dec 8, 2020 at 6:11 PM Seymour J Metz  wrote:
>
> Some new feature added new bit to, e.g., control registers, parameters, 
> tables.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Peter Van Dyke [pdvand...@gmail.com]
> Sent: Tuesday, December 8, 2020 6:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining required z/series hardware level - REVISED
>
> If there isn't a ready made solution available, the High Level Assembler
> Toolkit has a disassembler utility which could provide the input to a new
> tool that scans the assembler instructions and matches them to the hardware
> level. The IBM File Manager 'View Load Module' or VLM function can also
> disassemble CSECTs. VLM is also able to provide information such as the
> compiler used to create a CSECT and the compiler options used such as the
> ARCH setting.
>
> Regards,
> Peter Van Dyke
> HCL Software
>
> On Wed, 9 Dec 2020 at 07:27, Charles Mills  wrote:
>
> > "Version of the compiler" is not sufficient to answer "what hardware level
> > is required?" For example, COBOL 6.3 lets you specify ARCH() 8, 9, 10, 11,
> > 12 or 13. So the object code might run on a z10, or it might require a z15,
> > or anything in-between.
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Farley, Peter x23353
> > Sent: Tuesday, December 8, 2020 3:17 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Determining required z/series hardware level - REVISED
> >
> > It's not foolproof, but for both HLL's and assembler the COBANALZ program
> > in
> > CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess
> > at
> > the compiler or assembler version that generated the code.  From that you
> > could extrapolate the minimum hardware level required based on the
> > announcement letter for that release of each language's compiler.  Crude,
> > but possible, though COBANLZ does not handle "unbound object code", only
> > executables (load module or P.O.).
> >
> > For HLL compilers that allow you to generate the pseudo-assembler
> > equivalent
> > of the compiled code, you can analyze the compiler listing for instruction
> > uses, but if you only have executable code, obviously that is no help.
> >
> > For executable-only (no source or listing available) assembler, you would
> > need to decode the executable into instructions and data (not trivial by
> > any
> > means) to build a list of instructions used.  An instruction trace program
> > like TRACE390 in CBT file 391 could help there, assuming you have the files
> > and JCL needed to run the program once through the trace program.  The
> > trace
> > output would provide you with a list of instructions executed to analyze
> > for
> > hardware level.  The caveat there is that AFAIK CBT file 391 has not been
> > updated in quite a while and lacks many of the newer z-architecture
> > instructions, not least the whole suite of vector instructions.
> >
> > Running any kind of instruction trace has the caveat that not all
> > instruction paths are guaranteed to be executed, and there could easily be
> > instructions requiring a higher architecture level hiding in un-executed
> > code.
> >
> > In general, if all you have is executable code, I would call this one of
> > those "hard problems".
> >
> > Peter
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of
> > Mike Hochee
> > Sent: Tuesday, December 8, 2020 5:50 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Determining required z/series hardware level - REVISED
> >
> > Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'
> >
> > Hi,
> >
> > I'm looking for a utility/program which is capable of reading a z/OS
> > executable, whether an lmod or program object, or unbound object code, and
> > examining it for hardware/architecture level compatibility. I'm not
> > specifically referring to the ARCLVL of on the SYSSTATE macro, although I
> > know there is some correspondence, but rather to the set of unprivileged
> > instructions introduced at a particular hardware architecture levels.
> > Apologies in advance for any imprecise/inaccurate  terminology.
> >
> > For example, let's say I ha

Re: does anyone recall any details about MVS/XA?

[Seymour J Metz]

You needed an MVS driver system to install MVS/XA. Most customers already had 
an existing MVS/SP system, and didn't need to order the starter system. IPO and 
PSO were available later. Optional souce was available on tape. There was no 
PTF optional source; if the module was hit by service, you had to rely on the 
microfiche.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mark S Waterbury [01c3f560aac1-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, December 8, 2020 3:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: does anyone recall any details about MVS/XA?

Hi, all,

Does anyone recall how MVS/XA was first distributed and installed?  e.g. was 
there some kind of  a "starter system"?  If so, what was it? MVS 3.8J, or 
MVS/SE or MVS/SP or what?

I seem to recall that someone told me that there was no longer any "SYSGEN" 
process used to install MVS/XA?  So, how was this task accomplished?

Also, does anyone recall whether IBM made available any "optional source 
materials" for MVS/XA, either machine readable, on magnetic tape, or was that 
only available on microfiche, if it was available at all?

Thanks in advance for any details anyone can provide.

All the best,

Mark S. Waterbury

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

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

Re: Determining required z/series hardware level - REVISED

[Charles Mills]

Yeah, disassemblers are not magic. There is a loss of information going from 
source code to object code, and there is no tool that magically makes that 
information reappear.

I am not familiar with File Manager. I am looking at example "Load Module 
Information" for a load module compile with the IBM C++ compiler with ARCH 
specified, and I do not see the ARCH displayed by File Manager.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Tuesday, December 8, 2020 3:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

As one who has actually used the Assembler Toolkit disassembler for "lost 
source, lost listings" cases, I would warn anyone looking to use it that it 
requires quite a lot of customization and experimentation with multiple utility 
options for each executable you need to analyze, and many repeated runs until 
you get something truly usable out of it.

It works, but it makes you work too, and work quite hard.

Not having IBM File Manager available to me, I can’t speak to its accuracy or 
usability.

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

Re: does anyone recall any details about MVS/XA?

[Seymour J Metz]

You could use PUTs for maintenance, and most shops did. While you could freeze 
the system for a long time and then install a new IPO or PDO, that wasn't the 
norm.

Sysgen wasn't needed once MVSCP was available, and it eventually went away.

When you ordered IBM software, certain items were always shipped. Other items 
were only shipped if you specified an appropriate feature code on the order. 
Optional source code is source code that is not needed to install the product 
and and is only shipped if you specify the feature code)s).


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Brian France [b...@psu.edu]
Sent: Tuesday, December 8, 2020 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA?

I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.

SYSGEN I think was still needed for XA and maybe ESA.

I'm not sure what you meant by Optional Source Materials. If by that you
meant optional source code to install, I think they went the microsloth
bloat ware option later...

On 12/8/2020 4:00 PM, Joe Monk wrote:
> i  thought MVS/XA was CBIPO?
>
> Joe
>
> On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
> 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Hi, all,
>>
>> Does anyone recall how MVS/XA was first distributed and installed?  e.g.
>> was there some kind of  a "starter system"?  If so, what was it? MVS 3.8J,
>> or MVS/SE or MVS/SP or what?
>>
>> I seem to recall that someone told me that there was no longer any
>> "SYSGEN" process used to install MVS/XA?  So, how was this task
>> accomplished?
>>
>> Also, does anyone recall whether IBM made available any "optional source
>> materials" for MVS/XA, either machine readable, on magnetic tape, or was
>> that only available on microfiche, if it was available at all?
>>
>> Thanks in advance for any details anyone can provide.
>>
>> All the best,
>>
>> Mark S. Waterbury
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

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

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

Re: Determining required z/series hardware level - REVISED

[Mike Schwab]

Is the facility to check for the facility bits often present in load
modules?  I. E. a certain opcode or SVC call?  Then hou could look at
the bits being checked.

On Tue, Dec 8, 2020 at 6:11 PM Seymour J Metz  wrote:
>
> Some new feature added new bit to, e.g., control registers, parameters, 
> tables.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Peter Van Dyke [pdvand...@gmail.com]
> Sent: Tuesday, December 8, 2020 6:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining required z/series hardware level - REVISED
>
> If there isn't a ready made solution available, the High Level Assembler
> Toolkit has a disassembler utility which could provide the input to a new
> tool that scans the assembler instructions and matches them to the hardware
> level. The IBM File Manager 'View Load Module' or VLM function can also
> disassemble CSECTs. VLM is also able to provide information such as the
> compiler used to create a CSECT and the compiler options used such as the
> ARCH setting.
>
> Regards,
> Peter Van Dyke
> HCL Software
>
> On Wed, 9 Dec 2020 at 07:27, Charles Mills  wrote:
>
> > "Version of the compiler" is not sufficient to answer "what hardware level
> > is required?" For example, COBOL 6.3 lets you specify ARCH() 8, 9, 10, 11,
> > 12 or 13. So the object code might run on a z10, or it might require a z15,
> > or anything in-between.
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Farley, Peter x23353
> > Sent: Tuesday, December 8, 2020 3:17 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Determining required z/series hardware level - REVISED
> >
> > It's not foolproof, but for both HLL's and assembler the COBANALZ program
> > in
> > CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess
> > at
> > the compiler or assembler version that generated the code.  From that you
> > could extrapolate the minimum hardware level required based on the
> > announcement letter for that release of each language's compiler.  Crude,
> > but possible, though COBANLZ does not handle "unbound object code", only
> > executables (load module or P.O.).
> >
> > For HLL compilers that allow you to generate the pseudo-assembler
> > equivalent
> > of the compiled code, you can analyze the compiler listing for instruction
> > uses, but if you only have executable code, obviously that is no help.
> >
> > For executable-only (no source or listing available) assembler, you would
> > need to decode the executable into instructions and data (not trivial by
> > any
> > means) to build a list of instructions used.  An instruction trace program
> > like TRACE390 in CBT file 391 could help there, assuming you have the files
> > and JCL needed to run the program once through the trace program.  The
> > trace
> > output would provide you with a list of instructions executed to analyze
> > for
> > hardware level.  The caveat there is that AFAIK CBT file 391 has not been
> > updated in quite a while and lacks many of the newer z-architecture
> > instructions, not least the whole suite of vector instructions.
> >
> > Running any kind of instruction trace has the caveat that not all
> > instruction paths are guaranteed to be executed, and there could easily be
> > instructions requiring a higher architecture level hiding in un-executed
> > code.
> >
> > In general, if all you have is executable code, I would call this one of
> > those "hard problems".
> >
> > Peter
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of
> > Mike Hochee
> > Sent: Tuesday, December 8, 2020 5:50 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Determining required z/series hardware level - REVISED
> >
> > Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'
> >
> > Hi,
> >
> > I'm looking for a utility/program which is capable of reading a z/OS
> > executable, whether an lmod or program object, or unbound object code, and
> > examining it for hardware/architecture level compatibility. I'm not
> > specifically referring to the ARCLVL of on the SYSSTATE macro, although I
> > know there is some correspondence, but rather to the set of unprivileged
> > instructions introduced at a particular hardware architecture levels.
> > Apologies in advance for any imprecise/inaccurate  terminology.
> >
> > For example, let's say I happen to know that the most recently introduced
> > z/Series instruction used by a particular executable is the AHI
> > instruction,
> > then I would expect this utility/program to output 'G10', suggesting the
> > minimum hardware architecture required to support execution.
> >
> > I understand things are not always black/white in this area and could be
> > clouded by instruction facility requirements, etc..
> >
> > Thanks

Re: does anyone recall any details about MVS/XA?

[Seymour J Metz]

VM/XA MA was the first VM/XA, so I wouldn't call it special.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, December 8, 2020 4:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA?

ISTR there was also a special version of VM/XA made available "early" so that 
customers could run both 24-bit MVS/SP and 31-bit MVS/XA on the same physical 
machine.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian France
Sent: Tuesday, December 8, 2020 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA?

I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.

SYSGEN I think was still needed for XA and maybe ESA.

I'm not sure what you meant by Optional Source Materials. If by that you meant 
optional source code to install, I think they went the microsloth bloat ware 
option later...

On 12/8/2020 4:00 PM, Joe Monk wrote:
> i  thought MVS/XA was CBIPO?
>
> Joe
>
> On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
> 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Hi, all,
>>
>> Does anyone recall how MVS/XA was first distributed and installed?  e.g.
>> was there some kind of  a "starter system"?  If so, what was it? MVS
>> 3.8J, or MVS/SE or MVS/SP or what?
>>
>> I seem to recall that someone told me that there was no longer any
>> "SYSGEN" process used to install MVS/XA?  So, how was this task
>> accomplished?
>>
>> Also, does anyone recall whether IBM made available any "optional
>> source materials" for MVS/XA, either machine readable, on magnetic
>> tape, or was that only available on microfiche, if it was available at all?
>>
>> Thanks in advance for any details anyone can provide.
>>
>> All the best,
>>
>> Mark S. Waterbury
>>

--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

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

Re: does anyone recall any details about MVS/XA? [EXTERNAL]

[Seymour J Metz]

As I recall MVS, Express was tailored to your I/O configuration, so you had 
more flexibility in your IOCDS.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Feller, Paul [02fc94e14c43-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, December 8, 2020 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]

For those new to MVS there was the MVS/XA Express option.  You have to qualify 
to get it.  A shop I worked at a long time ago was a VSE shop that was going to 
convert to MVS and that is how we started off.  I believe the MVS/XA Express 
was a complete IPL system that IBM built based on your environment.  I think it 
was basically a restore and IPL type situation.  After that I don't recall what 
had to be done.  It was a long (long) time ago so the memory is a little fuzzy.



Thanks..

Paul Feller
GTS Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, December 8, 2020 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]

The *fun* memories of a POR before every time we tested MVS/XA and then another 
one when we went back to MVS/SP for production just returned.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://urldefense.proofpoint.com/v2/url?u=https-3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com&d=DwIFaQ&c=9g4MJkl2VjLjS6R4ei18BA&r=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc&m=KK1yXXNOBVuutibinfGrz7q-E8DxWAgMfozPwM_fdas&s=Aeq0PrNdOcRqdsiFkHkGJt4xsGO8Guev3vSwvmvSc-s&e=

‐‐‐ Original Message ‐‐‐

On Tuesday, December 8th, 2020 at 4:18 PM, Farley, Peter x23353 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> ISTR there was also a special version of VM/XA made available "early" so that 
> customers could run both 24-bit MVS/SP and 31-bit MVS/XA on the same physical 
> machine.
>
> Peter
>
> -Original Message-
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf
> Of Brian France
>
> Sent: Tuesday, December 8, 2020 4:11 PM
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Re: does anyone recall any details about MVS/XA?
>
> I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.
>
> SYSGEN I think was still needed for XA and maybe ESA.
>
> I'm not sure what you meant by Optional Source Materials. If by that you 
> meant optional source code to install, I think they went the microsloth bloat 
> ware option later...
>
> On 12/8/2020 4:00 PM, Joe Monk wrote:
>
> > i thought MVS/XA was CBIPO?
> >
> > Joe
> >
> > On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
> >
> > 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Hi, all,
> > >
> > > Does anyone recall how MVS/XA was first distributed and installed? e.g.
> > >
> > > was there some kind of a "starter system"? If so, what was it? MVS
> > >
> > > 3.8J, or MVS/SE or MVS/SP or what?
> > >
> > > I seem to recall that someone told me that there was no longer any
> > >
> > > "SYSGEN" process used to install MVS/XA? So, how was this task
> > >
> > > accomplished?
> > >
> > > Also, does anyone recall whether IBM made available any "optional
> > >
> > > source materials" for MVS/XA, either machine readable, on magnetic
> > >
> > > tape, or was that only available on microfiche, if it was available at 
> > > all?
> > >
> > > Thanks in advance for any details anyone can provide.
> > >
> > > All the best,
> > >
> > > Mark S. Waterbury
>
> Brian W. France
>
> Systems Administrator (Mainframe)
>
> Pennsylvania State University
>
> Penn State IT - Infrastructure/SYSARC
>
> Rm 25 Shields Bldg., University Park, Pa. 16802
>
> 814-863-4739
>
> b...@psu.edu
>
> There's no such thing as The Cloud - it's just someone else's computer...
>
> "To make an apple pie from scratch, you must first invent the universe."
>
> Carl Sagan
>
> --
> --
> --
> --
> --
> -
>
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
>

Re: Has anyone integrated Rexx with IKJPARS?

[Seymour J Metz]

XPROC sounds right. Thanks.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Wayne Driscoll [wdrisc...@rocketsoftware.com]
Sent: Tuesday, December 8, 2020 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Has anyone integrated Rexx with IKJPARS?

Just catching up. You may be referring to “XPROC” which is on file 772 of the 
CBT tape, which I’ve used in private rexx execs.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.

From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, November 19, 2020 5:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Has anyone integrated Rexx with IKJPARS?

EXTERNAL EMAIL



There is an old REXX-callable package called something like XPARSE that uses 
IKJPARSE.


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



From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Jesse 
1 Robinson mailto:jesse1.robin...@sce.com>>
Sent: Thursday, November 19, 2020 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Has anyone integrated Rexx with IKJPARS?

No argument. Still, it's hard to beat the flexibility of TSO/CLIST parameter 
handling. I wrote a TSO command once partly for kicks. Really complicated. 
Pointers to pointers to pointers. When it was done, it was super easy to use. 
Sigh.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Jeremy 
Nicoll
Sent: Thursday, November 19, 2020 12:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Has anyone integrated Rexx with IKJPARS?

*** EXTERNAL EMAIL - Use caution when opening links or attachments ***

On Thu, 19 Nov 2020, at 19:30, Charles Mills wrote:
> It would appear to be a lot of work, but it would seem that "TSO
> format command parsing" and Rexx would be a natural marriage.
>
> I have never used IKJPARS, so I don't claim to be an expert, and
> others might disagree.

Surely very few people use command line TSO though? Isn't it more common if 
there's something complicated to do to offer the user an ispf panel (which will 
remember previous parameter choices) to set up the options they want?

Also, even if you do make TSO REXX IKJPARS-capable, all you're doing is making 
REXX inconsistent across all the different subsystems that it's usable in.




> The issue I am struggling with is that for all of Rexx's parsing
> power, which is of course legendary, it does not seem well-suited to classic 
> "MVS"
> (for want of a better term) quoted strings. I am considering an EXEC
> that would accept parameters of
>
> 'a quoted string', 'another quoted string', simpletoken1, simpletoken2, ...

Why do you need quoted strings?

Something I do in some situations is make the very first character of an 
arbitrary string a delimiter, and then wherever that same character appears 
later on, the string gets chopped up on that. So

> 'now isn''t the time', 'nor, is this', MYTOKEN, YOURTOKEN

might become

!now isn't the time!nor, is this!MYTOKEN!YOURTOKEN

(I also sometimes have an escaped blank character so that an exec that expects 
a single token as its argument could be given

!the!meaning!of!life

but still process that as "the meaning of life".

Or I pass tokens which are: c2x(whatever)



--
Jeremy Nicoll - my opinions are my own.


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


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately 

Re: Determining required z/series hardware level - REVISED

[Seymour J Metz]

Some new feature added new bit to, e.g., control registers, parameters, tables.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Peter Van Dyke [pdvand...@gmail.com]
Sent: Tuesday, December 8, 2020 6:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

If there isn't a ready made solution available, the High Level Assembler
Toolkit has a disassembler utility which could provide the input to a new
tool that scans the assembler instructions and matches them to the hardware
level. The IBM File Manager 'View Load Module' or VLM function can also
disassemble CSECTs. VLM is also able to provide information such as the
compiler used to create a CSECT and the compiler options used such as the
ARCH setting.

Regards,
Peter Van Dyke
HCL Software

On Wed, 9 Dec 2020 at 07:27, Charles Mills  wrote:

> "Version of the compiler" is not sufficient to answer "what hardware level
> is required?" For example, COBOL 6.3 lets you specify ARCH() 8, 9, 10, 11,
> 12 or 13. So the object code might run on a z10, or it might require a z15,
> or anything in-between.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Tuesday, December 8, 2020 3:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining required z/series hardware level - REVISED
>
> It's not foolproof, but for both HLL's and assembler the COBANALZ program
> in
> CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess
> at
> the compiler or assembler version that generated the code.  From that you
> could extrapolate the minimum hardware level required based on the
> announcement letter for that release of each language's compiler.  Crude,
> but possible, though COBANLZ does not handle "unbound object code", only
> executables (load module or P.O.).
>
> For HLL compilers that allow you to generate the pseudo-assembler
> equivalent
> of the compiled code, you can analyze the compiler listing for instruction
> uses, but if you only have executable code, obviously that is no help.
>
> For executable-only (no source or listing available) assembler, you would
> need to decode the executable into instructions and data (not trivial by
> any
> means) to build a list of instructions used.  An instruction trace program
> like TRACE390 in CBT file 391 could help there, assuming you have the files
> and JCL needed to run the program once through the trace program.  The
> trace
> output would provide you with a list of instructions executed to analyze
> for
> hardware level.  The caveat there is that AFAIK CBT file 391 has not been
> updated in quite a while and lacks many of the newer z-architecture
> instructions, not least the whole suite of vector instructions.
>
> Running any kind of instruction trace has the caveat that not all
> instruction paths are guaranteed to be executed, and there could easily be
> instructions requiring a higher architecture level hiding in un-executed
> code.
>
> In general, if all you have is executable code, I would call this one of
> those "hard problems".
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of
> Mike Hochee
> Sent: Tuesday, December 8, 2020 5:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining required z/series hardware level - REVISED
>
> Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'
>
> Hi,
>
> I'm looking for a utility/program which is capable of reading a z/OS
> executable, whether an lmod or program object, or unbound object code, and
> examining it for hardware/architecture level compatibility. I'm not
> specifically referring to the ARCLVL of on the SYSSTATE macro, although I
> know there is some correspondence, but rather to the set of unprivileged
> instructions introduced at a particular hardware architecture levels.
> Apologies in advance for any imprecise/inaccurate  terminology.
>
> For example, let's say I happen to know that the most recently introduced
> z/Series instruction used by a particular executable is the AHI
> instruction,
> then I would expect this utility/program to output 'G10', suggesting the
> minimum hardware architecture required to support execution.
>
> I understand things are not always black/white in this area and could be
> clouded by instruction facility requirements, etc..
>
> Thanks in advance for any suggestions, guidance.
>
> Mike
> --
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
>

Re: does anyone recall any details about MVS/XA? [EXTERNAL]

[Seymour J Metz]

GENERATE rebuilds the target datasets from the distribution data sets; you 
still need an MVS/SP system generation or MVSCP to define the I/O 
configuration. I don't recall IPO ever using GENERATE, but memory is the second 
thing to go.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Lennie Dymoke-Bradshaw [032fff1be9b4-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, December 8, 2020 6:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]

I ran these CBIPO installs in the early eighties. I am pretty sure it used 
SMP/E to perform the generation using the GENERATE command.
I had an MVS/SP driving system of course. The first MVS/XA system I built was 
XA 2.1.2 I think.

Lennie Dymoke-Bradshaw
Consultant working on contract for BMC mainframe Services by RSM Partners
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: 08 December 2020 22:30
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]

Paul,

Thank you for that memory jog.  Yep, it was MVS/Express.  It was a stand-alone 
restore tape of MVS/XA (ours was 2.1.7) that once restored was an IPLable XA 
system - and reasonably current on maintenance.

Fun time was going to a class for MVS newbies and using the MVS/express tape.  
8 of us trying to restore stand-alone tapes on top of a VM 4381.  Watching the 
tape turn ever-so-slowly trying to load MVS.

So when we initially brought up XA 2.1.7, it was the express tape which was the 
starter system soon followed by a CBIPO tape to load down a more current set of 
software and yes, there was a SYSGEN in the middle of the CBIPO install process.

Those are old, rusty memories.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Feller, Paul
Sent: Tuesday, December 8, 2020 4:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]

For those new to MVS there was the MVS/XA Express option.  You have to qualify 
to get it.  A shop I worked at a long time ago was a VSE shop that was going to 
convert to MVS and that is how we started off.  I believe the MVS/XA Express 
was a complete IPL system that IBM built based on your environment.  I think it 
was basically a restore and IPL type situation.  After that I don't recall what 
had to be done.  It was a long (long) time ago so the memory is a little fuzzy.



Thanks..

Paul Feller
GTS Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, December 8, 2020 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]

The *fun* memories of a POR before every time we tested MVS/XA and then another 
one when we went back to MVS/SP for production just returned.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://urldefense.proofpoint.com/v2/url?u=https-3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com&d=DwIFaQ&c=9g4MJkl2VjLjS6R4ei18BA&r=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc&m=KK1yXXNOBVuutibinfGrz7q-E8DxWAgMfozPwM_fdas&s=Aeq0PrNdOcRqdsiFkHkGJt4xsGO8Guev3vSwvmvSc-s&e=

‐‐‐ Original Message ‐‐‐

On Tuesday, December 8th, 2020 at 4:18 PM, Farley, Peter x23353 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> ISTR there was also a special version of VM/XA made available "early" so that 
> customers could run both 24-bit MVS/SP and 31-bit MVS/XA on the same physical 
> machine.
>
> Peter
>
> -Original Message-
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf
> Of Brian France
>
> Sent: Tuesday, December 8, 2020 4:11 PM
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Re: does anyone recall any details about MVS/XA?
>
> I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.
>
> SYSGEN I think was still needed for XA and maybe ESA.
>
> I'm not sure what you meant by Optional Source Materials. If by that you 
> meant optional source code to install, I think they went the microsloth bloat 
> ware option later...
>
> On 12/8/2020 4:00 PM, Joe Monk wrote:
>
> > i thought MVS/XA was CBIPO?
> >
> > Joe
> >
> > On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
> >
> > 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Hi, all,
> > >
> > > Does anyone recall how MVS/XA was first distributed and installed? e.g.
> > >
> > > was there some kind of a "starter system"? If so, what was it? MVS
> > >
> > > 3.8J, or MVS/SE or MVS/SP or what?
> > >
> > > I seem to recall that someone told me that there was no longer any
> > >
> > > "SYSGEN" process used to install MVS/XA? So, how was this task
> > >
> > > accompli

Re: Determining required z/series hardware level - REVISED

[Farley, Peter x23353]

As one who has actually used the Assembler Toolkit disassembler for "lost 
source, lost listings" cases, I would warn anyone looking to use it that it 
requires quite a lot of customization and experimentation with multiple utility 
options for each executable you need to analyze, and many repeated runs until 
you get something truly usable out of it.

It works, but it makes you work too, and work quite hard.

Not having IBM File Manager available to me, I can’t speak to its accuracy or 
usability.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Van Dyke
Sent: Tuesday, December 8, 2020 6:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

If there isn't a ready made solution available, the High Level Assembler 
Toolkit has a disassembler utility which could provide the input to a new tool 
that scans the assembler instructions and matches them to the hardware level. 
The IBM File Manager 'View Load Module' or VLM function can also disassemble 
CSECTs. VLM is also able to provide information such as the compiler used to 
create a CSECT and the compiler options used such as the ARCH setting.

Regards,
Peter Van Dyke
HCL Software

On Wed, 9 Dec 2020 at 07:27, Charles Mills  wrote:

> "Version of the compiler" is not sufficient to answer "what hardware 
> level is required?" For example, COBOL 6.3 lets you specify ARCH() 8, 
> 9, 10, 11,
> 12 or 13. So the object code might run on a z10, or it might require a 
> z15, or anything in-between.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Farley, Peter x23353
> Sent: Tuesday, December 8, 2020 3:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining required z/series hardware level - REVISED
>
> It's not foolproof, but for both HLL's and assembler the COBANALZ 
> program in CBT file 321 will give you (in the SUMMARY DD output) a 
> pretty good guess at the compiler or assembler version that generated 
> the code.  From that you could extrapolate the minimum hardware level 
> required based on the announcement letter for that release of each 
> language's compiler.  Crude, but possible, though COBANLZ does not 
> handle "unbound object code", only executables (load module or P.O.).
>
> For HLL compilers that allow you to generate the pseudo-assembler 
> equivalent of the compiled code, you can analyze the compiler listing 
> for instruction uses, but if you only have executable code, obviously 
> that is no help.
>
> For executable-only (no source or listing available) assembler, you 
> would need to decode the executable into instructions and data (not 
> trivial by any
> means) to build a list of instructions used.  An instruction trace 
> program like TRACE390 in CBT file 391 could help there, assuming you 
> have the files and JCL needed to run the program once through the 
> trace program.  The trace output would provide you with a list of 
> instructions executed to analyze for hardware level.  The caveat there 
> is that AFAIK CBT file 391 has not been updated in quite a while and 
> lacks many of the newer z-architecture instructions, not least the 
> whole suite of vector instructions.
>
> Running any kind of instruction trace has the caveat that not all 
> instruction paths are guaranteed to be executed, and there could 
> easily be instructions requiring a higher architecture level hiding in 
> un-executed code.
>
> In general, if all you have is executable code, I would call this one 
> of those "hard problems".
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Mike Hochee
> Sent: Tuesday, December 8, 2020 5:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining required z/series hardware level - REVISED
>
> Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'
>
> Hi,
>
> I'm looking for a utility/program which is capable of reading a z/OS 
> executable, whether an lmod or program object, or unbound object code, 
> and examining it for hardware/architecture level compatibility. I'm 
> not specifically referring to the ARCLVL of on the SYSSTATE macro, 
> although I know there is some correspondence, but rather to the set of 
> unprivileged instructions introduced at a particular hardware architecture 
> levels.
> Apologies in advance for any imprecise/inaccurate  terminology.
>
> For example, let's say I happen to know that the most recently 
> introduced z/Series instruction used by a particular executable is the 
> AHI instruction, then I would expect this utility/program to output 
> 'G10', suggesting the minimum hardware architecture required to 
> support execution.
>
> I understand things are not always black/white in this area and could 
> be clouded by instruction facility requirements, etc..
>
> Thanks in advance for any suggestions, guidance.
>
> Mike
--

This message and any attachments 

Re: Determining required z/series hardware level - REVISED

[Farley, Peter x23353]

True, and also true for the XLC and PL1 compilers.  I did say "crude", and I 
meant it.

OTOH, if the executable is an HLL from one of the more recent compiler levels 
which use LE control blocks, ARCHLVL output can be found (or added to) the very 
detailed HLL information that CONANALZ can/could generate in its SYSPRINT 
output stream.

SMOP.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Tuesday, December 8, 2020 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

EXTERNAL EMAIL

"Version of the compiler" is not sufficient to answer "what hardware level is 
required?" For example, COBOL 6.3 lets you specify ARCH() 8, 9, 10, 11,
12 or 13. So the object code might run on a z10, or it might require a z15, or 
anything in-between.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Tuesday, December 8, 2020 3:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

It's not foolproof, but for both HLL's and assembler the COBANALZ program in 
CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess at 
the compiler or assembler version that generated the code.  From that you could 
extrapolate the minimum hardware level required based on the announcement 
letter for that release of each language's compiler.  Crude, but possible, 
though COBANLZ does not handle "unbound object code", only executables (load 
module or P.O.).

For HLL compilers that allow you to generate the pseudo-assembler equivalent of 
the compiled code, you can analyze the compiler listing for instruction uses, 
but if you only have executable code, obviously that is no help.

For executable-only (no source or listing available) assembler, you would need 
to decode the executable into instructions and data (not trivial by any
means) to build a list of instructions used.  An instruction trace program like 
TRACE390 in CBT file 391 could help there, assuming you have the files and JCL 
needed to run the program once through the trace program.  The trace output 
would provide you with a list of instructions executed to analyze for hardware 
level.  The caveat there is that AFAIK CBT file 391 has not been updated in 
quite a while and lacks many of the newer z-architecture instructions, not 
least the whole suite of vector instructions.

Running any kind of instruction trace has the caveat that not all instruction 
paths are guaranteed to be executed, and there could easily be instructions 
requiring a higher architecture level hiding in un-executed code.

In general, if all you have is executable code, I would call this one of those 
"hard problems".

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Hochee
Sent: Tuesday, December 8, 2020 5:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'  

Hi,

I'm looking for a utility/program which is capable of reading a z/OS 
executable, whether an lmod or program object, or unbound object code, and 
examining it for hardware/architecture level compatibility. I'm not 
specifically referring to the ARCLVL of on the SYSSTATE macro, although I know 
there is some correspondence, but rather to the set of unprivileged 
instructions introduced at a particular hardware architecture levels.
Apologies in advance for any imprecise/inaccurate  terminology.

For example, let's say I happen to know that the most recently introduced 
z/Series instruction used by a particular executable is the AHI instruction, 
then I would expect this utility/program to output 'G10', suggesting the 
minimum hardware architecture required to support execution.

I understand things are not always black/white in this area and could be 
clouded by instruction facility requirements, etc..

Thanks in advance for any suggestions, guidance.

Mike
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential.
If the reader of the message is not the intended recipient or an authorized 
representative of the intended recipient, you are hereby notified that any 
dissemination of this communication is strictly prohibited. If you have 
received this communication in error, please notify us immediately by e-mail 
and delete the message and any attachments from your system.

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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@li

Re: Determining required z/series hardware level - REVISED

[Peter Van Dyke]

If there isn't a ready made solution available, the High Level Assembler
Toolkit has a disassembler utility which could provide the input to a new
tool that scans the assembler instructions and matches them to the hardware
level. The IBM File Manager 'View Load Module' or VLM function can also
disassemble CSECTs. VLM is also able to provide information such as the
compiler used to create a CSECT and the compiler options used such as the
ARCH setting.

Regards,
Peter Van Dyke
HCL Software

On Wed, 9 Dec 2020 at 07:27, Charles Mills  wrote:

> "Version of the compiler" is not sufficient to answer "what hardware level
> is required?" For example, COBOL 6.3 lets you specify ARCH() 8, 9, 10, 11,
> 12 or 13. So the object code might run on a z10, or it might require a z15,
> or anything in-between.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Tuesday, December 8, 2020 3:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining required z/series hardware level - REVISED
>
> It's not foolproof, but for both HLL's and assembler the COBANALZ program
> in
> CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess
> at
> the compiler or assembler version that generated the code.  From that you
> could extrapolate the minimum hardware level required based on the
> announcement letter for that release of each language's compiler.  Crude,
> but possible, though COBANLZ does not handle "unbound object code", only
> executables (load module or P.O.).
>
> For HLL compilers that allow you to generate the pseudo-assembler
> equivalent
> of the compiled code, you can analyze the compiler listing for instruction
> uses, but if you only have executable code, obviously that is no help.
>
> For executable-only (no source or listing available) assembler, you would
> need to decode the executable into instructions and data (not trivial by
> any
> means) to build a list of instructions used.  An instruction trace program
> like TRACE390 in CBT file 391 could help there, assuming you have the files
> and JCL needed to run the program once through the trace program.  The
> trace
> output would provide you with a list of instructions executed to analyze
> for
> hardware level.  The caveat there is that AFAIK CBT file 391 has not been
> updated in quite a while and lacks many of the newer z-architecture
> instructions, not least the whole suite of vector instructions.
>
> Running any kind of instruction trace has the caveat that not all
> instruction paths are guaranteed to be executed, and there could easily be
> instructions requiring a higher architecture level hiding in un-executed
> code.
>
> In general, if all you have is executable code, I would call this one of
> those "hard problems".
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of
> Mike Hochee
> Sent: Tuesday, December 8, 2020 5:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determining required z/series hardware level - REVISED
>
> Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'
>
> Hi,
>
> I'm looking for a utility/program which is capable of reading a z/OS
> executable, whether an lmod or program object, or unbound object code, and
> examining it for hardware/architecture level compatibility. I'm not
> specifically referring to the ARCLVL of on the SYSSTATE macro, although I
> know there is some correspondence, but rather to the set of unprivileged
> instructions introduced at a particular hardware architecture levels.
> Apologies in advance for any imprecise/inaccurate  terminology.
>
> For example, let's say I happen to know that the most recently introduced
> z/Series instruction used by a particular executable is the AHI
> instruction,
> then I would expect this utility/program to output 'G10', suggesting the
> minimum hardware architecture required to support execution.
>
> I understand things are not always black/white in this area and could be
> clouded by instruction facility requirements, etc..
>
> Thanks in advance for any suggestions, guidance.
>
> Mike
> --
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail
> and delete the message and any attachments from your system.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
>

Re: Determining required z/series hardware level - REVISED

[Charles Mills]

"Version of the compiler" is not sufficient to answer "what hardware level
is required?" For example, COBOL 6.3 lets you specify ARCH() 8, 9, 10, 11,
12 or 13. So the object code might run on a z10, or it might require a z15,
or anything in-between.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Tuesday, December 8, 2020 3:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

It's not foolproof, but for both HLL's and assembler the COBANALZ program in
CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess at
the compiler or assembler version that generated the code.  From that you
could extrapolate the minimum hardware level required based on the
announcement letter for that release of each language's compiler.  Crude,
but possible, though COBANLZ does not handle "unbound object code", only
executables (load module or P.O.).

For HLL compilers that allow you to generate the pseudo-assembler equivalent
of the compiled code, you can analyze the compiler listing for instruction
uses, but if you only have executable code, obviously that is no help.

For executable-only (no source or listing available) assembler, you would
need to decode the executable into instructions and data (not trivial by any
means) to build a list of instructions used.  An instruction trace program
like TRACE390 in CBT file 391 could help there, assuming you have the files
and JCL needed to run the program once through the trace program.  The trace
output would provide you with a list of instructions executed to analyze for
hardware level.  The caveat there is that AFAIK CBT file 391 has not been
updated in quite a while and lacks many of the newer z-architecture
instructions, not least the whole suite of vector instructions.

Running any kind of instruction trace has the caveat that not all
instruction paths are guaranteed to be executed, and there could easily be
instructions requiring a higher architecture level hiding in un-executed
code.

In general, if all you have is executable code, I would call this one of
those "hard problems".

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Mike Hochee
Sent: Tuesday, December 8, 2020 5:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'  

Hi,

I'm looking for a utility/program which is capable of reading a z/OS
executable, whether an lmod or program object, or unbound object code, and
examining it for hardware/architecture level compatibility. I'm not
specifically referring to the ARCLVL of on the SYSSTATE macro, although I
know there is some correspondence, but rather to the set of unprivileged
instructions introduced at a particular hardware architecture levels.
Apologies in advance for any imprecise/inaccurate  terminology.

For example, let's say I happen to know that the most recently introduced
z/Series instruction used by a particular executable is the AHI instruction,
then I would expect this utility/program to output 'G10', suggesting the
minimum hardware architecture required to support execution.

I understand things are not always black/white in this area and could be
clouded by instruction facility requirements, etc..

Thanks in advance for any suggestions, guidance.

Mike
--

This message and any attachments are intended only for the use of the
addressee and may contain information that is privileged and confidential.
If the reader of the message is not the intended recipient or an authorized
representative of the intended recipient, you are hereby notified that any
dissemination of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by e-mail
and delete the message and any attachments from your system.

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

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

Re: Determining required z/series hardware level - REVISED

[Charles Mills]

So the utility would loop through the object code looking for opcodes, and
when it found one it would know the required hardware level, and keep track
of the maximum found?

Interesting idea. I have never heard of such a utility, but it could be
attempted. Finding op codes is an imperfect science because it is hard
sometimes to tell an opcode from other data. And of course some of the newer
instructions are not "just an opcode" -- there are other bits besides the
first 8 that specify the particular instruction.

If the programs are compiled by a modern compiler I suspect the compiled
ARCH level may be in the LE control blocks, but that is just a guess. It
that were the case, and that were sufficient, then this is a fairly easy
project, and certainly a well-defined project that could be done "perfectly"
(as opposed to "imperfect science").

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mike Hochee
Sent: Tuesday, December 8, 2020 2:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'  

Hi,

I'm looking for a utility/program which is capable of reading a z/OS
executable, whether an lmod or program object, or unbound object code, and
examining it for hardware/architecture level compatibility. I'm not
specifically referring to the ARCLVL of on the SYSSTATE macro, although I
know there is some correspondence, but rather to the set of unprivileged
instructions introduced at a particular hardware architecture levels.
Apologies in advance for any imprecise/inaccurate  terminology.

For example, let's say I happen to know that the most recently introduced
z/Series instruction used by a particular executable is the AHI instruction,
then I would expect this utility/program to output 'G10', suggesting the
minimum hardware architecture required to support execution.

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

Re: does anyone recall any details about MVS/XA? [EXTERNAL]

[Lennie Dymoke-Bradshaw]

I ran these CBIPO installs in the early eighties. I am pretty sure it used 
SMP/E to perform the generation using the GENERATE command.
I had an MVS/SP driving system of course. The first MVS/XA system I built was 
XA 2.1.2 I think.

Lennie Dymoke-Bradshaw
Consultant working on contract for BMC mainframe Services by RSM Partners
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: 08 December 2020 22:30
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]

Paul,

Thank you for that memory jog.  Yep, it was MVS/Express.  It was a stand-alone 
restore tape of MVS/XA (ours was 2.1.7) that once restored was an IPLable XA 
system - and reasonably current on maintenance.  

Fun time was going to a class for MVS newbies and using the MVS/express tape.  
8 of us trying to restore stand-alone tapes on top of a VM 4381.  Watching the 
tape turn ever-so-slowly trying to load MVS.  

So when we initially brought up XA 2.1.7, it was the express tape which was the 
starter system soon followed by a CBIPO tape to load down a more current set of 
software and yes, there was a SYSGEN in the middle of the CBIPO install process.

Those are old, rusty memories.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Feller, Paul
Sent: Tuesday, December 8, 2020 4:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]

For those new to MVS there was the MVS/XA Express option.  You have to qualify 
to get it.  A shop I worked at a long time ago was a VSE shop that was going to 
convert to MVS and that is how we started off.  I believe the MVS/XA Express 
was a complete IPL system that IBM built based on your environment.  I think it 
was basically a restore and IPL type situation.  After that I don't recall what 
had to be done.  It was a long (long) time ago so the memory is a little fuzzy. 

 

Thanks.. 
  
Paul Feller
GTS Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, December 8, 2020 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]

The *fun* memories of a POR before every time we tested MVS/XA and then another 
one when we went back to MVS/SP for production just returned.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://urldefense.proofpoint.com/v2/url?u=https-3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com&d=DwIFaQ&c=9g4MJkl2VjLjS6R4ei18BA&r=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc&m=KK1yXXNOBVuutibinfGrz7q-E8DxWAgMfozPwM_fdas&s=Aeq0PrNdOcRqdsiFkHkGJt4xsGO8Guev3vSwvmvSc-s&e=
 

‐‐‐ Original Message ‐‐‐

On Tuesday, December 8th, 2020 at 4:18 PM, Farley, Peter x23353 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> ISTR there was also a special version of VM/XA made available "early" so that 
> customers could run both 24-bit MVS/SP and 31-bit MVS/XA on the same physical 
> machine.
>
> Peter
>
> -Original Message-
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf 
> Of Brian France
>
> Sent: Tuesday, December 8, 2020 4:11 PM
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Re: does anyone recall any details about MVS/XA?
>
> I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.
>
> SYSGEN I think was still needed for XA and maybe ESA.
>
> I'm not sure what you meant by Optional Source Materials. If by that you 
> meant optional source code to install, I think they went the microsloth bloat 
> ware option later...
>
> On 12/8/2020 4:00 PM, Joe Monk wrote:
>
> > i thought MVS/XA was CBIPO?
> >
> > Joe
> >
> > On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
> >
> > 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Hi, all,
> > >
> > > Does anyone recall how MVS/XA was first distributed and installed? e.g.
> > >
> > > was there some kind of a "starter system"? If so, what was it? MVS
> > >
> > > 3.8J, or MVS/SE or MVS/SP or what?
> > >
> > > I seem to recall that someone told me that there was no longer any
> > >
> > > "SYSGEN" process used to install MVS/XA? So, how was this task
> > >
> > > accomplished?
> > >
> > > Also, does anyone recall whether IBM made available any "optional
> > >
> > > source materials" for MVS/XA, either machine readable, on magnetic
> > >
> > > tape, or was that only available on microfiche, if it was available at 
> > > all?
> > >
> > > Thanks in advance for any details anyone can provide.
> > >
> > > All the best,
> > >
> > > Mark S. Waterbury
>
> Brian W. France
>
> Systems Administrator (Mainframe)
>
> Pennsylvania State University
>
> Penn State IT - Infrastructure/SYSARC
>
> Rm 25 Shields Bldg., University Park, Pa. 16802
>
> 814-863-4739
>
> b...@psu.edu
>
> There's no

Re: Determining required z/series hardware level - REVISED

[Farley, Peter x23353]

It's not foolproof, but for both HLL's and assembler the COBANALZ program in 
CBT file 321 will give you (in the SUMMARY DD output) a pretty good guess at 
the compiler or assembler version that generated the code.  From that you could 
extrapolate the minimum hardware level required based on the announcement 
letter for that release of each language's compiler.  Crude, but possible, 
though COBANLZ does not handle "unbound object code", only executables (load 
module or P.O.).

For HLL compilers that allow you to generate the pseudo-assembler equivalent of 
the compiled code, you can analyze the compiler listing for instruction uses, 
but if you only have executable code, obviously that is no help.

For executable-only (no source or listing available) assembler, you would need 
to decode the executable into instructions and data (not trivial by any means) 
to build a list of instructions used.  An instruction trace program like 
TRACE390 in CBT file 391 could help there, assuming you have the files and JCL 
needed to run the program once through the trace program.  The trace output 
would provide you with a list of instructions executed to analyze for hardware 
level.  The caveat there is that AFAIK CBT file 391 has not been updated in 
quite a while and lacks many of the newer z-architecture instructions, not 
least the whole suite of vector instructions.

Running any kind of instruction trace has the caveat that not all instruction 
paths are guaranteed to be executed, and there could easily be instructions 
requiring a higher architecture level hiding in un-executed code.

In general, if all you have is executable code, I would call this one of those 
"hard problems".

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Hochee
Sent: Tuesday, December 8, 2020 5:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determining required z/series hardware level - REVISED

Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'  

Hi,

I'm looking for a utility/program which is capable of reading a z/OS 
executable, whether an lmod or program object, or unbound object code, and 
examining it for hardware/architecture level compatibility. I'm not 
specifically referring to the ARCLVL of on the SYSSTATE macro, although I know 
there is some correspondence, but rather to the set of unprivileged 
instructions introduced at a particular hardware architecture levels. Apologies 
in advance for any imprecise/inaccurate  terminology.

For example, let's say I happen to know that the most recently introduced 
z/Series instruction used by a particular executable is the AHI instruction, 
then I would expect this utility/program to output 'G10', suggesting the 
minimum hardware architecture required to support execution.

I understand things are not always black/white in this area and could be 
clouded by instruction facility requirements, etc..

Thanks in advance for any suggestions, guidance.

Mike
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Determining required z/series hardware level - REVISED

[Mike Hochee]

Oops, got the hardware lvl for AHI wrong, so changed 'G9' to 'G10'  

Hi,

I'm looking for a utility/program which is capable of reading a z/OS 
executable, whether an lmod or program object, or unbound object code, and 
examining it for hardware/architecture level compatibility. I'm not 
specifically referring to the ARCLVL of on the SYSSTATE macro, although I know 
there is some correspondence, but rather to the set of unprivileged 
instructions introduced at a particular hardware architecture levels. Apologies 
in advance for any imprecise/inaccurate  terminology.

For example, let's say I happen to know that the most recently introduced 
z/Series instruction used by a particular executable is the AHI instruction, 
then I would expect this utility/program to output 'G10', suggesting the 
minimum hardware architecture required to support execution.

I understand things are not always black/white in this area and could be 
clouded by instruction facility requirements, etc..

Thanks in advance for any suggestions, guidance.

Mike


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

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

Re: Has anyone integrated Rexx with IKJPARS?

[Wayne Driscoll]

Just catching up. You may be referring to “XPROC” which is on file 772 of the 
CBT tape, which I’ve used in private rexx execs.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.

From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, November 19, 2020 5:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Has anyone integrated Rexx with IKJPARS?

EXTERNAL EMAIL



There is an old REXX-callable package called something like XPARSE that uses 
IKJPARSE.


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



From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Jesse 
1 Robinson mailto:jesse1.robin...@sce.com>>
Sent: Thursday, November 19, 2020 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Has anyone integrated Rexx with IKJPARS?

No argument. Still, it's hard to beat the flexibility of TSO/CLIST parameter 
handling. I wrote a TSO command once partly for kicks. Really complicated. 
Pointers to pointers to pointers. When it was done, it was super easy to use. 
Sigh.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Jeremy 
Nicoll
Sent: Thursday, November 19, 2020 12:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Has anyone integrated Rexx with IKJPARS?

*** EXTERNAL EMAIL - Use caution when opening links or attachments ***

On Thu, 19 Nov 2020, at 19:30, Charles Mills wrote:
> It would appear to be a lot of work, but it would seem that "TSO
> format command parsing" and Rexx would be a natural marriage.
>
> I have never used IKJPARS, so I don't claim to be an expert, and
> others might disagree.

Surely very few people use command line TSO though? Isn't it more common if 
there's something complicated to do to offer the user an ispf panel (which will 
remember previous parameter choices) to set up the options they want?

Also, even if you do make TSO REXX IKJPARS-capable, all you're doing is making 
REXX inconsistent across all the different subsystems that it's usable in.




> The issue I am struggling with is that for all of Rexx's parsing
> power, which is of course legendary, it does not seem well-suited to classic 
> "MVS"
> (for want of a better term) quoted strings. I am considering an EXEC
> that would accept parameters of
>
> 'a quoted string', 'another quoted string', simpletoken1, simpletoken2, ...

Why do you need quoted strings?

Something I do in some situations is make the very first character of an 
arbitrary string a delimiter, and then wherever that same character appears 
later on, the string gets chopped up on that. So

> 'now isn''t the time', 'nor, is this', MYTOKEN, YOURTOKEN

might become

!now isn't the time!nor, is this!MYTOKEN!YOURTOKEN

(I also sometimes have an escaped blank character so that an exec that expects 
a single token as its argument could be given

!the!meaning!of!life

but still process that as "the meaning of life".

Or I pass tokens which are: c2x(whatever)



--
Jeremy Nicoll - my opinions are my own.


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


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Determining required z/series hardware level

[Mike Hochee]

Hi,

I'm looking for a utility/program which is capable of reading a z/OS 
executable, whether an lmod or program object, or unbound object code, and 
examining it for hardware/architecture level compatibility. I'm not 
specifically referring to the ARCLVL of on the SYSSTATE macro, although I know 
there is some correspondence, but rather to the set of unprivileged 
instructions introduced at a particular hardware architecture levels. Apologies 
in advance for any imprecise/inaccurate  terminology.

For example, let's say I happen to know that the most recently introduced 
z/Series instruction used by a particular executable is the AHI instruction, 
then I would expect this utility/program to output 'G9', suggesting the minimum 
hardware architecture required to support execution.

I understand things are not always black/white in this area and could be 
clouded by instruction facility requirements, etc..

Thanks in advance for any suggestions, guidance.

Mike


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

Re: does anyone recall any details about MVS/XA? [EXTERNAL]

[Pommier, Rex]

Paul,

Thank you for that memory jog.  Yep, it was MVS/Express.  It was a stand-alone 
restore tape of MVS/XA (ours was 2.1.7) that once restored was an IPLable XA 
system - and reasonably current on maintenance.  

Fun time was going to a class for MVS newbies and using the MVS/express tape.  
8 of us trying to restore stand-alone tapes on top of a VM 4381.  Watching the 
tape turn ever-so-slowly trying to load MVS.  

So when we initially brought up XA 2.1.7, it was the express tape which was the 
starter system soon followed by a CBIPO tape to load down a more current set of 
software and yes, there was a SYSGEN in the middle of the CBIPO install process.

Those are old, rusty memories.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Feller, Paul
Sent: Tuesday, December 8, 2020 4:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]

For those new to MVS there was the MVS/XA Express option.  You have to qualify 
to get it.  A shop I worked at a long time ago was a VSE shop that was going to 
convert to MVS and that is how we started off.  I believe the MVS/XA Express 
was a complete IPL system that IBM built based on your environment.  I think it 
was basically a restore and IPL type situation.  After that I don't recall what 
had to be done.  It was a long (long) time ago so the memory is a little fuzzy. 

 

Thanks.. 
  
Paul Feller
GTS Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, December 8, 2020 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]

The *fun* memories of a POR before every time we tested MVS/XA and then another 
one when we went back to MVS/SP for production just returned.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://urldefense.proofpoint.com/v2/url?u=https-3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com&d=DwIFaQ&c=9g4MJkl2VjLjS6R4ei18BA&r=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc&m=KK1yXXNOBVuutibinfGrz7q-E8DxWAgMfozPwM_fdas&s=Aeq0PrNdOcRqdsiFkHkGJt4xsGO8Guev3vSwvmvSc-s&e=
 

‐‐‐ Original Message ‐‐‐

On Tuesday, December 8th, 2020 at 4:18 PM, Farley, Peter x23353 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> ISTR there was also a special version of VM/XA made available "early" so that 
> customers could run both 24-bit MVS/SP and 31-bit MVS/XA on the same physical 
> machine.
>
> Peter
>
> -Original Message-
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf 
> Of Brian France
>
> Sent: Tuesday, December 8, 2020 4:11 PM
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Re: does anyone recall any details about MVS/XA?
>
> I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.
>
> SYSGEN I think was still needed for XA and maybe ESA.
>
> I'm not sure what you meant by Optional Source Materials. If by that you 
> meant optional source code to install, I think they went the microsloth bloat 
> ware option later...
>
> On 12/8/2020 4:00 PM, Joe Monk wrote:
>
> > i thought MVS/XA was CBIPO?
> >
> > Joe
> >
> > On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
> >
> > 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Hi, all,
> > >
> > > Does anyone recall how MVS/XA was first distributed and installed? e.g.
> > >
> > > was there some kind of a "starter system"? If so, what was it? MVS
> > >
> > > 3.8J, or MVS/SE or MVS/SP or what?
> > >
> > > I seem to recall that someone told me that there was no longer any
> > >
> > > "SYSGEN" process used to install MVS/XA? So, how was this task
> > >
> > > accomplished?
> > >
> > > Also, does anyone recall whether IBM made available any "optional
> > >
> > > source materials" for MVS/XA, either machine readable, on magnetic
> > >
> > > tape, or was that only available on microfiche, if it was available at 
> > > all?
> > >
> > > Thanks in advance for any details anyone can provide.
> > >
> > > All the best,
> > >
> > > Mark S. Waterbury
>
> Brian W. France
>
> Systems Administrator (Mainframe)
>
> Pennsylvania State University
>
> Penn State IT - Infrastructure/SYSARC
>
> Rm 25 Shields Bldg., University Park, Pa. 16802
>
> 814-863-4739
>
> b...@psu.edu
>
> There's no such thing as The Cloud - it's just someone else's computer...
>
> "To make an apple pie from scratch, you must first invent the universe."
>
> Carl Sagan
>
> --
> --
> --
> --
> --
> -
>
> This message and any attachments are intended only for the use of the 

Re: does anyone recall any details about MVS/XA? [EXTERNAL]

[Feller, Paul]

For those new to MVS there was the MVS/XA Express option.  You have to qualify 
to get it.  A shop I worked at a long time ago was a VSE shop that was going to 
convert to MVS and that is how we started off.  I believe the MVS/XA Express 
was a complete IPL system that IBM built based on your environment.  I think it 
was basically a restore and IPL type situation.  After that I don't recall what 
had to be done.  It was a long (long) time ago so the memory is a little fuzzy. 

 

Thanks.. 
  
Paul Feller
GTS Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, December 8, 2020 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL]

The *fun* memories of a POR before every time we tested MVS/XA and then another 
one when we went back to MVS/SP for production just returned.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://urldefense.proofpoint.com/v2/url?u=https-3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com&d=DwIFaQ&c=9g4MJkl2VjLjS6R4ei18BA&r=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc&m=KK1yXXNOBVuutibinfGrz7q-E8DxWAgMfozPwM_fdas&s=Aeq0PrNdOcRqdsiFkHkGJt4xsGO8Guev3vSwvmvSc-s&e=
 

‐‐‐ Original Message ‐‐‐

On Tuesday, December 8th, 2020 at 4:18 PM, Farley, Peter x23353 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> ISTR there was also a special version of VM/XA made available "early" so that 
> customers could run both 24-bit MVS/SP and 31-bit MVS/XA on the same physical 
> machine.
>
> Peter
>
> -Original Message-
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf 
> Of Brian France
>
> Sent: Tuesday, December 8, 2020 4:11 PM
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Re: does anyone recall any details about MVS/XA?
>
> I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.
>
> SYSGEN I think was still needed for XA and maybe ESA.
>
> I'm not sure what you meant by Optional Source Materials. If by that you 
> meant optional source code to install, I think they went the microsloth bloat 
> ware option later...
>
> On 12/8/2020 4:00 PM, Joe Monk wrote:
>
> > i thought MVS/XA was CBIPO?
> >
> > Joe
> >
> > On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
> >
> > 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Hi, all,
> > >
> > > Does anyone recall how MVS/XA was first distributed and installed? e.g.
> > >
> > > was there some kind of a "starter system"? If so, what was it? MVS
> > >
> > > 3.8J, or MVS/SE or MVS/SP or what?
> > >
> > > I seem to recall that someone told me that there was no longer any
> > >
> > > "SYSGEN" process used to install MVS/XA? So, how was this task
> > >
> > > accomplished?
> > >
> > > Also, does anyone recall whether IBM made available any "optional
> > >
> > > source materials" for MVS/XA, either machine readable, on magnetic
> > >
> > > tape, or was that only available on microfiche, if it was available at 
> > > all?
> > >
> > > Thanks in advance for any details anyone can provide.
> > >
> > > All the best,
> > >
> > > Mark S. Waterbury
>
> Brian W. France
>
> Systems Administrator (Mainframe)
>
> Pennsylvania State University
>
> Penn State IT - Infrastructure/SYSARC
>
> Rm 25 Shields Bldg., University Park, Pa. 16802
>
> 814-863-4739
>
> b...@psu.edu
>
> There's no such thing as The Cloud - it's just someone else's computer...
>
> "To make an apple pie from scratch, you must first invent the universe."
>
> Carl Sagan
>
> --
> --
> --
> --
> --
> -
>
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
>
>
> --
> --
> --
> --
> --
> --
> --

Re: [EXTERNAL] Re: does anyone recall any details about MVS/XA?

[Horne, Jim]

In my first shop we did a conversion from OS/VS1 straight to MVS/XA (IBM made 
us an offer we couldn't refuse).  This was a little before CBIPO so first had 
to lay down a starter system that was some flavor of MVS/370 or /SP.  I say 
that because it ran under our VM/SP (actually HPO) system.  Before we could 
start working on the MVS/XA system itself we had to install VM/XA which was in 
the process of being invented.  The very first VM/XA for customers was VM/XA 
Migration Aid, followed as quickly as possible by VM/XA System Facility release 
1 which was in turn followed about 6 months later by release 2.  My boss and I 
knew all the VM/XA level 2 people by their first names.  We definitely 'got' to 
do the stage 1 and stage 2 MVS gens once we got that far.

Looking back on it is fondly nostalgic but it was a constant pain at the time - 
but, boy oh boy, did we learn things!  Good times.  I don't think this helps 
the original poster much, but it did bring back memories

Jim Horne

-Original Message-

ISTR there was also a special version of VM/XA made available "early" so that 
customers could run both 24-bit MVS/SP and 31-bit MVS/XA on the same physical 
machine.

Peter

I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.

SYSGEN I think was still needed for XA and maybe ESA.

I'm not sure what you meant by Optional Source Materials. If by that you meant 
optional source code to install, I think they went the microsloth bloat ware 
option later...

On 12/8/2020 4:00 PM, Joe Monk wrote:
> i  thought MVS/XA was CBIPO?
>
> Joe
>
> On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
> 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Hi, all,
>>
>> Does anyone recall how MVS/XA was first distributed and installed?  e.g.
>> was there some kind of  a "starter system"?  If so, what was it? MVS
>> 3.8J, or MVS/SE or MVS/SP or what?
>>
>> I seem to recall that someone told me that there was no longer any
>> "SYSGEN" process used to install MVS/XA?  So, how was this task
>> accomplished?
>>
>> Also, does anyone recall whether IBM made available any "optional
>> source materials" for MVS/XA, either machine readable, on magnetic
>> tape, or was that only available on microfiche, if it was available at all?
>>
>> Thanks in advance for any details anyone can provide.
>>
>> All the best,
>>
>> Mark S. Waterbury
>>

--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instru

Re: does anyone recall any details about MVS/XA?

[Mark Jacobs]

The *fun* memories of a POR before every time we tested MVS/XA and then another 
one when we went back to MVS/SP for production just returned.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐

On Tuesday, December 8th, 2020 at 4:18 PM, Farley, Peter x23353 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> ISTR there was also a special version of VM/XA made available "early" so that 
> customers could run both 24-bit MVS/SP and 31-bit MVS/XA on the same physical 
> machine.
>
> Peter
>
> -Original Message-
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of 
> Brian France
>
> Sent: Tuesday, December 8, 2020 4:11 PM
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Re: does anyone recall any details about MVS/XA?
>
> I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.
>
> SYSGEN I think was still needed for XA and maybe ESA.
>
> I'm not sure what you meant by Optional Source Materials. If by that you 
> meant optional source code to install, I think they went the microsloth bloat 
> ware option later...
>
> On 12/8/2020 4:00 PM, Joe Monk wrote:
>
> > i thought MVS/XA was CBIPO?
> >
> > Joe
> >
> > On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
> >
> > 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Hi, all,
> > >
> > > Does anyone recall how MVS/XA was first distributed and installed? e.g.
> > >
> > > was there some kind of a "starter system"? If so, what was it? MVS
> > >
> > > 3.8J, or MVS/SE or MVS/SP or what?
> > >
> > > I seem to recall that someone told me that there was no longer any
> > >
> > > "SYSGEN" process used to install MVS/XA? So, how was this task
> > >
> > > accomplished?
> > >
> > > Also, does anyone recall whether IBM made available any "optional
> > >
> > > source materials" for MVS/XA, either machine readable, on magnetic
> > >
> > > tape, or was that only available on microfiche, if it was available at 
> > > all?
> > >
> > > Thanks in advance for any details anyone can provide.
> > >
> > > All the best,
> > >
> > > Mark S. Waterbury
>
> Brian W. France
>
> Systems Administrator (Mainframe)
>
> Pennsylvania State University
>
> Penn State IT - Infrastructure/SYSARC
>
> Rm 25 Shields Bldg., University Park, Pa. 16802
>
> 814-863-4739
>
> b...@psu.edu
>
> There's no such thing as The Cloud - it's just someone else's computer...
>
> "To make an apple pie from scratch, you must first invent the universe."
>
> Carl Sagan
>
> ---
>
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
>
>
> -
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: does anyone recall any details about MVS/XA?

[Farley, Peter x23353]

ISTR there was also a special version of VM/XA made available "early" so that 
customers could run both 24-bit MVS/SP and 31-bit MVS/XA on the same physical 
machine.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian France
Sent: Tuesday, December 8, 2020 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: does anyone recall any details about MVS/XA?

I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.

SYSGEN I think was still needed for XA and maybe ESA.

I'm not sure what you meant by Optional Source Materials. If by that you meant 
optional source code to install, I think they went the microsloth bloat ware 
option later...

On 12/8/2020 4:00 PM, Joe Monk wrote:
> i  thought MVS/XA was CBIPO?
>
> Joe
>
> On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury < 
> 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Hi, all,
>>
>> Does anyone recall how MVS/XA was first distributed and installed?  e.g.
>> was there some kind of  a "starter system"?  If so, what was it? MVS 
>> 3.8J, or MVS/SE or MVS/SP or what?
>>
>> I seem to recall that someone told me that there was no longer any 
>> "SYSGEN" process used to install MVS/XA?  So, how was this task 
>> accomplished?
>>
>> Also, does anyone recall whether IBM made available any "optional 
>> source materials" for MVS/XA, either machine readable, on magnetic 
>> tape, or was that only available on microfiche, if it was available at all?
>>
>> Thanks in advance for any details anyone can provide.
>>
>> All the best,
>>
>> Mark S. Waterbury
>>

--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: does anyone recall any details about MVS/XA?

[Joe Monk]

Yes, and I believe the "driving' system for install had to be MVS/SP or
higher...

Joe

On Tue, Dec 8, 2020 at 3:11 PM Brian France  wrote:

> I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.
>
> SYSGEN I think was still needed for XA and maybe ESA.
>
> I'm not sure what you meant by Optional Source Materials. If by that you
> meant optional source code to install, I think they went the microsloth
> bloat ware option later...
>
> On 12/8/2020 4:00 PM, Joe Monk wrote:
> > i  thought MVS/XA was CBIPO?
> >
> > Joe
> >
> > On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
> > 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> Hi, all,
> >>
> >> Does anyone recall how MVS/XA was first distributed and installed?  e.g.
> >> was there some kind of  a "starter system"?  If so, what was it? MVS
> 3.8J,
> >> or MVS/SE or MVS/SP or what?
> >>
> >> I seem to recall that someone told me that there was no longer any
> >> "SYSGEN" process used to install MVS/XA?  So, how was this task
> >> accomplished?
> >>
> >> Also, does anyone recall whether IBM made available any "optional source
> >> materials" for MVS/XA, either machine readable, on magnetic tape, or was
> >> that only available on microfiche, if it was available at all?
> >>
> >> Thanks in advance for any details anyone can provide.
> >>
> >> All the best,
> >>
> >> Mark S. Waterbury
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> Brian W. France
> Systems Administrator (Mainframe)
> Pennsylvania State University
> Penn State IT - Infrastructure/SYSARC
> Rm 25 Shields Bldg., University Park, Pa. 16802
> 814-863-4739
> b...@psu.edu
>
> There's no such thing as The Cloud - it's just someone else's computer...
>
> "To make an apple pie from scratch, you must first invent the universe."
>
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: does anyone recall any details about MVS/XA?

[Brian France]

I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint.

SYSGEN I think was still needed for XA and maybe ESA.

I'm not sure what you meant by Optional Source Materials. If by that you 
meant optional source code to install, I think they went the microsloth 
bloat ware option later...


On 12/8/2020 4:00 PM, Joe Monk wrote:

i  thought MVS/XA was CBIPO?

Joe

On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:


Hi, all,

Does anyone recall how MVS/XA was first distributed and installed?  e.g.
was there some kind of  a "starter system"?  If so, what was it? MVS 3.8J,
or MVS/SE or MVS/SP or what?

I seem to recall that someone told me that there was no longer any
"SYSGEN" process used to install MVS/XA?  So, how was this task
accomplished?

Also, does anyone recall whether IBM made available any "optional source
materials" for MVS/XA, either machine readable, on magnetic tape, or was
that only available on microfiche, if it was available at all?

Thanks in advance for any details anyone can provide.

All the best,

Mark S. Waterbury

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


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


--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

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

Re: does anyone recall any details about MVS/XA?

[Mark Jacobs]

It was ordered and installed using the CBIPO proceess, but the install needed 
to run on an existing MVS system.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐

On Tuesday, December 8th, 2020 at 4:00 PM, Joe Monk  wrote:

> i thought MVS/XA was CBIPO?
>
> Joe
>
> On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
>
> 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Hi, all,
> >
> > Does anyone recall how MVS/XA was first distributed and installed? e.g.
> >
> > was there some kind of a "starter system"? If so, what was it? MVS 3.8J,
> >
> > or MVS/SE or MVS/SP or what?
> >
> > I seem to recall that someone told me that there was no longer any
> >
> > "SYSGEN" process used to install MVS/XA? So, how was this task
> >
> > accomplished?
> >
> > Also, does anyone recall whether IBM made available any "optional source
> >
> > materials" for MVS/XA, either machine readable, on magnetic tape, or was
> >
> > that only available on microfiche, if it was available at all?
> >
> > Thanks in advance for any details anyone can provide.
> >
> > All the best,
> >
> > Mark S. Waterbury
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: does anyone recall any details about MVS/XA?

[Joe Monk]

i  thought MVS/XA was CBIPO?

Joe

On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury <
01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:

> Hi, all,
>
> Does anyone recall how MVS/XA was first distributed and installed?  e.g.
> was there some kind of  a "starter system"?  If so, what was it? MVS 3.8J,
> or MVS/SE or MVS/SP or what?
>
> I seem to recall that someone told me that there was no longer any
> "SYSGEN" process used to install MVS/XA?  So, how was this task
> accomplished?
>
> Also, does anyone recall whether IBM made available any "optional source
> materials" for MVS/XA, either machine readable, on magnetic tape, or was
> that only available on microfiche, if it was available at all?
>
> Thanks in advance for any details anyone can provide.
>
> All the best,
>
> Mark S. Waterbury
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: does anyone recall any details about MVS/XA?

[Mark Jacobs]

I installed MVS/XA under using our existing MVS/SP V1 system. For a new MVS 
customer I assume that IBM shipped a starter system like they do now which was 
a stripped down OS with just enough "stuff" to install the MVS/XA system.

As for your optional source material question, I don't remember, but likely 
they did.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐

On Tuesday, December 8th, 2020 at 3:04 PM, Mark S Waterbury 
<01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:

> Hi, all,
>
> Does anyone recall how MVS/XA was first distributed and installed? e.g. was 
> there some kind of a "starter system"? If so, what was it? MVS 3.8J, or 
> MVS/SE or MVS/SP or what?
>
> I seem to recall that someone told me that there was no longer any "SYSGEN" 
> process used to install MVS/XA? So, how was this task accomplished?
>
> Also, does anyone recall whether IBM made available any "optional source 
> materials" for MVS/XA, either machine readable, on magnetic tape, or was that 
> only available on microfiche, if it was available at all?
>
> Thanks in advance for any details anyone can provide.
>
> All the best,
>
> Mark S. Waterbury
>
> 
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

does anyone recall any details about MVS/XA?

[Mark S Waterbury]

Hi, all,

Does anyone recall how MVS/XA was first distributed and installed?  e.g. was 
there some kind of  a "starter system"?  If so, what was it? MVS 3.8J, or 
MVS/SE or MVS/SP or what?

I seem to recall that someone told me that there was no longer any "SYSGEN" 
process used to install MVS/XA?  So, how was this task accomplished?

Also, does anyone recall whether IBM made available any "optional source 
materials" for MVS/XA, either machine readable, on magnetic tape, or was that 
only available on microfiche, if it was available at all?

Thanks in advance for any details anyone can provide.

All the best,

Mark S. Waterbury

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

Re: SFTP Sortcard creating using DFSORT

[Sri h Kolusu]

> but the issue is the store_nbrs are of different length, the .csv is
> not getting created correctly . Could some one let me know how we
> can append the .csv also when the store is of variable length
>

Ron,

Try this DFSORT JCL

//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD *
 ITEM_NBR   }  ITEM_DESC1  }  STORE_NBR   }
+1+2+3+4+5+-
 500849599 }ENT MASSA TORTA 2 KG }33
 500878286 }CAST DE CAJU TS 120G }331
 500862526 }MTR MASS LASANH SECA }3
 500877131 }PERU INTEIR C MIUDOS }3323
 500034169 }ACUC FIT UNIAO   }3311
 500832360 }AMPOLA PANTENE UNIDA }33
//SORTOUT  DD SYSOUT=*
//SYSINDD *
  OPTION COPY,SKIPREC=1
  INREC PARSE=(%=(REPEAT=2,ENDAT=C'}'),
   %01=(ENDBEFR=C'{',
ENDBEFR=C' ',
FIXLEN=8)),
BUILD=(C' SPUT  ''',
   C'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01''',
   C' FUTRETAIL_',
   DATE1(-)-1,
   %01,JFY=(SHIFT=LEFT,
 LEAD=C'_',
TRAIL=C'.CSV',
LENGTH=16))

/*


Thanks,
Kolusu
DFSORT Development
IBM Corporation


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

Re: DFRMM tape movement JCL

[willie bunter]

 If I remember correctly the vaul pattern is defined in the VRS.
On Monday, December 7, 2020, 02:04:24 p.m. EST, Lizette Koehler 
 wrote:  
 
 Did you look in ISMF Option G Reports?

I think there are some in there

Lizette


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Monday, December 7, 2020 3:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFRMM tape movement JCL

Hello

Are there anyone who is still using offsite tapes (Vaults). Is there any 
specific JCLs are there to list the tapes in drive, list the tapes in vaults 
and movement inventory records to record movement of Tapes.

I did look into SYS1.SAMPLIB and ran some some report but still it gives me a 
wrong report about zero tapes in vault whereas we have 24 tapes in vault.

Could someone please point me in the right direction

zOS 2.2

Jake

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

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

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

SFTP Sortcard creating using DFSORT

[Ron Thomas]

Hello-

I am creating a dynamic SFTP sortcard using DFSORT, here in the Input file the 
Store_nbr is at position 40. I need the file to created as 

SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_33.csv


but the issue is the store_nbrs are of different length, the .csv is not 
getting created correctly . Could some one let me know how we can append the 
.csv also when the store is of variable length


Input File 

---+1+2+3+4+
 Top of Data
 ITEM_NBR   }  ITEM_DESC1  }  STORE_NBR   }
 500849599 }ENT MASSA TORTA 2 KG }33
 500878286 }CAST DE CAJU TS 120G }331
 500862526 }MTR MASS LASANH SECA }3
 500877131 }PERU INTEIR C MIUDOS }3323
 500034169 }ACUC FIT UNIAO   }3311
 500832360 }AMPOLA PANTENE UNIDA }33


output card generated 

SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_33
SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_331
SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_3
SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_3323
SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_3311
SPUT 'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01' FUTRETAIL_2020-12-07_33


Control Card used 

SORT FIELDS=COPY
OUTREC BUILD=(1:C'SPUT ',
6:C,7:C'K01.BB.RST.PTEM.FUTR.RTLDTA.REPT01',
41:C,
43:C'FUTRETAIL_',
53:DATE1(-)-1,63:C'_',64:40,4,21X)


Regards
Ron T

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

Re: How debug convoluted #ifdef logic/how get __opendir2() defined

[Charles Mills]

Thanks.

I am going to just live with my own declaration. I am too busy with real work 
to debug dirent.h. 

Thanks again,

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jantje.
Sent: Monday, December 7, 2020 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How debug convoluted #ifdef logic/how get __opendir2() defined

SKIPSRC(HIDE) compile option will hide any code that is excluded as a result of 
the #ifdef logic. From there, you will have to try the different candidate 
#define and run a compile after each modification of those. Yes, there will be 
a cominatorial explosion.

Sorry, I can't think of any better solution.

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