Re: ASMA032E Relocatable value or unresolved symbol found when absolute value required

[CM Poncelet]

I suspect that relocating FOO to be in CSECT SOME would not assemble
either, because it is the value of offset '*' that is not absolute (well
at least not when the source code is still being assembled).

Have you tried assembling this?

SOME  CSECT
  LLILF 2,FOO
FOO   EQU   *
OTHER CSECT


On 28/12/2016 03:45, Charles Mills wrote:
> Replying to everyone at once.
> 
>> Since they're in different CSECTs, the assembler will need to generate ESD
> and RLD 
>> entries since a Binder ORDER statement may muddle any relation between the
> addresses.
> 
> Assembler and binder do it all the time. Every instance of EXTRN FOO/DC
> A(FOO)
> 
>> But are long displacements relocatable?
>> But can it depend on the target's being within even long displacement
> reach?
> 
> No long displacement in the picture. 
> 
>> Maybe because your CSECT has not a USING for relocatable symbols.. 
> 
> USING applies to base-displacement situations. No base-displacement here.
> 
>> If you use an absolute value for an instruction you don't need any
> relocatable value.
> 
> Would seem to be a truism, no?
> 
> Charles
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Tuesday, December 27, 2016 5:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ASMA032E Relocatable value or unresolved symbol found when
> absolute value required
> 
> On 2016-12-27 18:01, Charles Mills wrote:
>> Why won't this assemble?
>>
>> SOME  CSECT
>>   LLILF 2,FOO
>> OTHER CSECT
>> FOO   EQU   *
>>
>> Why do I get ASMA032E Relocatable value or unresolved symbol found 
>> when absolute value required - FOO?
>>
>> Can't the assembler generate a relocatable address constant for the 
>> immediate operand of LLILF? Or am I doing something stupid that I am 
>> not seeing?
>>  
> Since they're in different CSECTs, the assembler will need to generate ESD
> and RLD entries since a Binder ORDER statement may muddle any relation
> between the addresses.  But are long displacements relocatable?
>   
>> DC A(FOO) at the same spot assembles with no problem. I could 
>> presumably code DC X'C02F',AL4(FOO) and it would execute correctly.
>>  
> 
> --
> 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: Looking for USERMOD samples

[retired mainframer]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Tuesday, December 27, 2016 1:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Looking for USERMOD samples
> 
> I'm trying to learn a little bit about SMP/E usermods.
> Unfortunately neither SMP/E manuals nor google did not provide good
> (*well explained*) samples.
> 
> 
> Example (from File Manager):
> //SMPCNTL  DD *
>   SET BDY(GLOBAL).
>   RECEIVE SELECT(FMN2001) SYSMODS.
>   SET BDY (TARGET).
>   APPLY SELECT(FMN2001) RETRY(YES) REDO.
> /*
> //SMPPTFIN DD DATA,DLM=$$
> ++USERMOD (FMN2001) REWORK(201601) .
> ++VER (Z038) FMID(JADLD12) PRE(UI25246) .
> ++JCLIN.
> /*
> ++SRC(FMN2POPT) TXLIB(FMN2SRC) DISTLIB(AFMNSAM1).
> $$
> FMN2SRC is a DD name pointing to a member with source code.

That is wrong.  It should identify the library.  The first operand following
the ++SRC identifies the member.

> Q1: How can I know what's target library for the load module?

If the source of FMN2OPT (SRC element) and the CSECT (MOD element) that
results from assembling it already exist in the CSI, then issuing a LIST
command against either will show you the corresponding target library.  It
appears as the SYSLIB.

If either does not exist, you get to define it as part of your input using
the SYSLIB operand and +JCLIN.

> Q2: there is no assemble or linkedit jobstep. I assume it comes from
SMP/E.

Yes. The only reason to APPLY an SRC is to assemble and link it.

> Q3: FMN2SRC DD - should it describe library or member? In other words:
> DSN=MY.LIB or DSN=MY.LIB(MEM) ?

There is a reason it is called TXLIB and not TXDATA.

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

Re: ASMA032E Relocatable value or unresolved symbol found when absolute value required

[Charles Mills]

You really need to come up to speed on modern opcodes. All of the performance 
improvements are in new opcodes; the old ones aren't getting any faster. There 
is some cool stuff, like ANDs and ORs of immediate values against registers, 
operations on the high word of registers (like getting 16 additional registers 
to play with!), and the ability to load 31 bits of a word into a 32- or 64-bit 
register. Lots and lots of new immediate instructions (including LLILF) because 
storage references are such performance killers. Load and store on condition, 
which lets you do the classic compare/jump around on condition/load -- without 
a jump, which is also a performance hit. (And I'm a C++ guy now)

It is not multiply relocatable. It must be relocated only by the load address 
of CSECT OTHER -- that's it. Multiply relocatable is crazy stuff like

ONE CSECT
X   DCA(X-Y)
TWO CSECT
Y   EQU   *

Nothing more in SYSPRINT except the source code reference and a helpful display 
of what the assembler made of it:   .

Unfortunately the FM is pretty clear: it must be absolute. All of the bits and 
pieces are there to make this work: the instruction would work if assembled. 
The assembler knows how to do this sort of thing and will do it in an 
A-constant. It's solvable: I have not asked the assembler and binder to know 
the unknowable. But the assembler in its high level wisdom does not support 
relocatable immediate operands. Made sense when the biggest immediate operand 
was 8 bits in CLI; it makes no sense in the 32-bit immediate operand context of 
LLILF. Sigh.

> or we can wait for Lizette to tell you to take this to ASSEMBLER-LIST

:-)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 27, 2016 7:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASMA032E Relocatable value or unresolved symbol found when 
absolute value required

On Tue, 27 Dec 2016 19:45:58 -0800, Charles Mills wrote:
>
>> Since they're in different CSECTs, the assembler will need to 
>> generate ESD
>and RLD
>> entries since a Binder ORDER statement may muddle any relation 
>> between the
>addresses.
>
>Assembler and binder do it all the time. Every instance of EXTRN FOO/DC
>A(FOO)
>
>> But are long displacements relocatable?
>> But can it depend on the target's being within even long displacement
>reach?
>
>No long displacement in the picture.
> 
Ok.  I'm modern Opcode-ignorant.  Is it a multiply-relocatable immediate 
operand?  Are multiply-relocatable immediate operands supported?

FOO appears to be (multiply) relocatable and ASMA032E says it requires 
absolute.  Does SYSPRINT tell you more about this?

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

Re: ASMA032E Relocatable value or unresolved symbol found when absolute value required

[Paul Gilmartin]

On Tue, 27 Dec 2016 19:45:58 -0800, Charles Mills wrote:
>
>> Since they're in different CSECTs, the assembler will need to generate ESD
>and RLD
>> entries since a Binder ORDER statement may muddle any relation between the
>addresses.
>
>Assembler and binder do it all the time. Every instance of EXTRN FOO/DC
>A(FOO)
>
>> But are long displacements relocatable?
>> But can it depend on the target's being within even long displacement
>reach?
>
>No long displacement in the picture.
> 
Ok.  I'm modern Opcode-ignorant.  Is it a multiply-relocatable immediate
operand?  Are multiply-relocatable immediate operands supported?

FOO appears to be (multiply) relocatable and ASMA032E says it
requires absolute.  Does SYSPRINT tell you more about this?


>> Why won't this assemble?
>>
>> SOME  CSECT
>>   LLILF 2,FOO
>> OTHER CSECT
>> FOO   EQU   *
>>
>> Why do I get ASMA032E Relocatable value or unresolved symbol found
>> when absolute value required - FOO?

... or we can wait for Lizette to tell you to take this to ASSEMBLER-LIST.

-- gil

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

Re: ASMA032E Relocatable value or unresolved symbol found when absolute value required

[Charles Mills]

I guess the answer is found in the Assembler manual: "Immediate data must be
specified as absolute expressions whose range of values depends on the
machine instruction for which the data is required."

There is no good reason why what I am attempting *should* not work. As I
said, if I code DC X'C02F',AL4(FOO) I believe I will get exactly what I
intended and it will execute as intended. But it doesn't work because it
doesn't work. It doesn't work because "immediate data must be specified as
absolute expressions."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, December 27, 2016 5:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ASMA032E Relocatable value or unresolved symbol found when absolute
value required

Why won't this assemble?

SOME  CSECT
  LLILF 2,FOO
OTHER CSECT
FOO   EQU   *

Why do I get ASMA032E Relocatable value or unresolved symbol found when
absolute value required - FOO?

Can't the assembler generate a relocatable address constant for the
immediate operand of LLILF? Or am I doing something stupid that I am not
seeing?

DC A(FOO) at the same spot assembles with no problem. I could presumably
code DC X'C02F',AL4(FOO) and it would execute correctly.

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

Re: ASMA032E Relocatable value or unresolved symbol found when absolute value required

[Charles Mills]

Replying to everyone at once.

> Since they're in different CSECTs, the assembler will need to generate ESD
and RLD 
> entries since a Binder ORDER statement may muddle any relation between the
addresses.

Assembler and binder do it all the time. Every instance of EXTRN FOO/DC
A(FOO)

> But are long displacements relocatable?
> But can it depend on the target's being within even long displacement
reach?

No long displacement in the picture. 

> Maybe because your CSECT has not a USING for relocatable symbols.. 

USING applies to base-displacement situations. No base-displacement here.

> If you use an absolute value for an instruction you don't need any
relocatable value.

Would seem to be a truism, no?

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Tuesday, December 27, 2016 5:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASMA032E Relocatable value or unresolved symbol found when
absolute value required

On 2016-12-27 18:01, Charles Mills wrote:
> Why won't this assemble?
> 
> SOME  CSECT
>   LLILF 2,FOO
> OTHER CSECT
> FOO   EQU   *
> 
> Why do I get ASMA032E Relocatable value or unresolved symbol found 
> when absolute value required - FOO?
> 
> Can't the assembler generate a relocatable address constant for the 
> immediate operand of LLILF? Or am I doing something stupid that I am 
> not seeing?
>  
Since they're in different CSECTs, the assembler will need to generate ESD
and RLD entries since a Binder ORDER statement may muddle any relation
between the addresses.  But are long displacements relocatable?

> DC A(FOO) at the same spot assembles with no problem. I could 
> presumably code DC X'C02F',AL4(FOO) and it would execute correctly.
>  

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

Thanks John Mckown

[Joseph Reichman]

John

Thanks that's what I was looking for only at the TCB level ( 2 different TCBs) 
can there be concurrent execution of code

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

Re: Multitasking question

[Paul Gilmartin]

On Tue, 27 Dec 2016 17:58:03 -0800, Anne & Lynn Wheeler  wrote:
>
>> Decades ago, I had experimented with similar techniques, even so far as
>> paired +- RLDs.  In the course of that, I discovered that CMS obeys its
>> own rules.  If I had unresolved WXTRN + absolute offset, it got relocated
>> anyway because CMS assumed the nonzero result meant the WXTRN was
>> resolved.
>
>re:
>http://www.garlic.com/~lynn/2016h.html#98 A Christmassy PL/I tale
>http://www.garlic.com/~lynn/2016h.html#101 Multitasking question
>
>part of the issue was that CMS had a 64kbyte os/360 system services
>simulation implementation. With the introduction of MVS ... and its
>8mbyte kernel image ... there was a joke that CMS 64kbyte os/360 system
>services simulation was significantly more effective than the MVS 8mbyte
>os/360 system services simulation.
>
If by "more effective" one means that CMS produced incorrect results faster
than OS produced correct results ...

And OS emulation I/O ignored Length Indicate reported by CP.

And OS emulation  failed to count the 4-byte RDW for RECFM=VB.

... but that made it plenty fast.

-- gil

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

Re: Multitasking question

[Anne & Lynn Wheeler]

000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes:
> Decades ago, I had experimented with similar techniques, even so far as
> paired +- RLDs.  In the course of that, I discovered that CMS obeys its
> own rules.  If I had unresolved WXTRN + absolute offset, it got relocated
> anyway because CMS assumed the nonzero result meant the WXTRN was
> resolved.

re:
http://www.garlic.com/~lynn/2016h.html#98 A Christmassy PL/I tale
http://www.garlic.com/~lynn/2016h.html#101 Multitasking question

part of the issue was that CMS had a 64kbyte os/360 system services
simulation implementation. With the introduction of MVS ... and its
8mbyte kernel image ... there was a joke that CMS 64kbyte os/360 system
services simulation was significantly more effective than the MVS 8mbyte
os/360 system services simulation.

In the mid-70s, somebody in the burlington vm370/cms development group
did a rewrite increasing the size to approx 128kbyte os/360 system
services simulation ... with lots more feature/function compatibility
(including read/write os/360 disks supporting file access methods).

However this was about the time that Future System was failing and the
mad rush to get stuff back into the 370 product pipelines ...  including
kicking off 3033, 3081/xa and mvs/xa. the head of POK tells corporate
that he needs vm370 product killed and all the people moved to POK or
otherwise he won't be able to ship mvs/xa on schedule (this is still
mid-70s). All the enhancements not already shipped ... disappear in the
shutdown of the burlington site.
http://www.garlic.com/~lynn/submain.html#futuresys

They were not planning on telling the burlington group until shortly
before the shutdown goes into effect, to minimize the number of people
that could escape the move. Unfortunately(?) the shutdown leaks several
months early and lots manage to escape (there was joke that the head of
POK is one of the major contributors to DEC vax/vms) ... and then there
was witchhunt to find who leaked the information ... fortunately, nobody
gave me up.

Endicott finally managed to save the vm370 product mission ... but they
had to reconstitute a development group from scratch ... and Endicott
was much more interested in providing dos/vs system service simulation
(than os/360 system services simulation)

lots of past post about location independent code and fighting RLDs
http://www.garlic.com/~lynn/submain.html#adcon

other multitasking tivia: charlie had invented compare (chosen
because CAS are his initials) ... while doing fine-grain cp67
multiprocessor locking at science center ... some posts
http://www.garlic.com/~lynn/subtopic.html#545tech
and
http://www.garlic.com/~lynn/subtopic.html#smp

attempting to get compre added to 370 was repulsed because the POK
favorite son operating system people said that test (from 360/65MP)
was more than sufficient. 370 architecture owners said that in order to
add compare to 370, uses other than SMP kernel locking was
needed. Thus was born the application multitasking/multithreaded
examples that still are included in appendix of POO. This was picked by
large mulithreaded/multitasking subsystems like DBMSes (IMS, DB2, etc).

In the 80s, other platforms started adding compare instructions (or
instructions with semantics similar to compare) ... as part of
supporting large commercial DBMS. Platforms w/o compare semantics
had to use kernel calls with significantly higher overhead.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Problem with "RECEIVE" of z/OS 2.2 upgrade

[Paul Gilmartin]

On 2016-12-27 18:28, McCabe, Ron wrote:
> As far as I know GIMUNZIP is my only alternative as that is what is used when 
> the JCL is created from the first step on the dialog panel.  Maybe I'm doing 
> a part that has already been done?  Here is what my dialog panel looks like...
> 
> CustomPac Order Management Menu
> 
> 
> R   RECEIVE  - Receive an Order
> 
> I   INSTALL  - Install an Order
> 
> Order Number ==>  (Leave blank to list uninstalled orders)
> 
> D   DISPLAY  - Select Orders to Display
> 
> Master dialog data set qualifiers: TM00.ZOS22.UPGRADE
> 
> I'm trying to do the R "RECEIVE" but maybe that has been done when I 
> downloaded the order to our mainframe?
>  
It would seem not; else the things would have been moved into SMPPTS or
temporary PDSes.

What does INSTALL do?  (It would still need to do a RECEIVE behind the scenes.
APPLY isn't UNIX-savvy.)

-- gil

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

Re: ASMA032E Relocatable value or unresolved symbol found when absolute value required

[Paul Gilmartin]

On 2016-12-27 18:01, Charles Mills wrote:
> Why won't this assemble?
> 
> SOME  CSECT
>   LLILF 2,FOO
> OTHER CSECT
> FOO   EQU   *
> 
> Why do I get ASMA032E Relocatable value or unresolved symbol found when
> absolute value required - FOO?
> 
> Can't the assembler generate a relocatable address constant for the
> immediate operand of LLILF? Or am I doing something stupid that I am not
> seeing?
>  
Since they're in different CSECTs, the assembler will need to generate
ESD and RLD entries since a Binder ORDER statement may muddle any
relation between the addresses.  But are long displacements relocatable?

> DC A(FOO) at the same spot assembles with no problem. I could presumably
> code DC X'C02F',AL4(FOO) and it would execute correctly.
>  
This seems to indicate that HLASM can manage the ESDs and RLDs.  But can
it depend on the target's being within even long displacement reach?

-- gil

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

Re: Problem with "RECEIVE" of z/OS 2.2 upgrade

[McCabe, Ron]

As far as I know GIMUNZIP is my only alternative as that is what is used when 
the JCL is created from the first step on the dialog panel.  Maybe I'm doing a 
part that has already been done?  Here is what my dialog panel looks like...

CustomPac Order Management Menu


R   RECEIVE  - Receive an Order

I   INSTALL  - Install an Order

Order Number ==>  (Leave blank to list uninstalled orders)

D   DISPLAY  - Select Orders to Display

Master dialog data set qualifiers: TM00.ZOS22.UPGRADE

I'm trying to do the R "RECEIVE" but maybe that has been done when I downloaded 
the order to our mainframe?

Thanks,
Ron McCabe
Mutual of Enumclaw


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 27, 2016 5:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problem with "RECEIVE" of z/OS 2.2 upgrade

On 2016-12-27 15:19, McCabe, Ron wrote:
> Yes, I need to GIMUNZIP.  All the files are in pax.z format on a ZFS file 
> system within our USS subsystem.
>
Looking earlier in this thread, it appears that it's IBM that wants you to 
GIMUNZ.

I wonder why?  It seems circuitous.

But do they give you no alternative?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

Re: Old MVS/SP

[W Mainframe]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; } Dave,
My idea is running a MVS/SP as a VM guest. Reasonable?
Dan
Sent from Yahoo Mail for iPhone


On Friday, December 23, 2016, 09:19, Dave Wade  wrote:

>You might want to look here:
>
>http://hercules-390.github.io/html/

Notwithstanding the I don't believe that Hercules implements the necessary 
assists to IPL MVS/SP natively, which is what you were told when you asked on 
the Hercules-390 list some time ago...

Dave Wade


>Am 22.12.2016 um 17:14 schrieb W Mainframe:
>  blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
>#715FFA solid !important; padding-left:1ex !important; background-color:white 
>!important; } Guys,
> Anyone is running a MVS/SP in some kind of emulator?
> Dan
>
>
> Sent from Yahoo Mail for iPhone
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Best regards
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: ASMA032E Relocatable value or unresolved symbol found when absolute value required

[Paul Gilmartin]

On Tue, 27 Dec 2016 17:01:40 -0800, Charles Mills wrote:

>Why won't this assemble?
>
>SOME  CSECT
>  LLILF 2,FOO
>OTHER CSECT
>FOO   EQU   *
>
>Why do I get ASMA032E Relocatable value or unresolved symbol found when
>absolute value required - FOO?
>
>Can't the assembler generate a relocatable address constant for the
>immediate operand of LLILF? Or am I doing something stupid that I am not
>seeing?
>
>DC A(FOO) at the same spot assembles with no problem. I could presumably
>code DC X'C02F',AL4(FOO) and it would execute correctly.
>
Conway's law; a disdain for reusable code.  Interestingly, I've encountered
somewhat the complement of this: a literal reference is accepted in a
12-bit address RS instruction; a syntax error in an S-type constant.
I suppose there might be some objection that allowing the latter would
open the gate to recursive literal definition.  But why fear recursion?

-- gil

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

Re: Multi SRB

[Ed Jaffe]

On 12/27/2016 4:40 PM, Tony Harminc wrote:


It's arguable that address spaces are dispatchable. But that perhaps
muddles the notions of dispatcher and scheduler (which these days is
really WLM).


Not arguable at all IMHO. Dispatchable units have WEB queue entries and 
address spaces don't have them.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: ASMA032E Relocatable value or unresolved symbol found when absolute value required

[W Mainframe]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; } Charles,
Maybe because your CSECT has not a USING for relocatable symbols.. If you use 
an absolute value for an instruction you don't need any relocatable value..
Could be a reason...
Dan

Sent from Yahoo Mail for iPhone


On Tuesday, December 27, 2016, 23:01, Charles Mills  wrote:

Why won't this assemble?

SOME  CSECT
      LLILF 2,FOO
OTHER CSECT
FOO  EQU  *

Why do I get ASMA032E Relocatable value or unresolved symbol found when
absolute value required - FOO?

Can't the assembler generate a relocatable address constant for the
immediate operand of LLILF? Or am I doing something stupid that I am not
seeing?

DC A(FOO) at the same spot assembles with no problem. I could presumably
code DC X'C02F',AL4(FOO) and it would execute correctly.

Charles 

--
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: Problem with "RECEIVE" of z/OS 2.2 upgrade

[Paul Gilmartin]

On 2016-12-27 15:19, McCabe, Ron wrote:
> Yes, I need to GIMUNZIP.  All the files are in pax.z format on a ZFS file 
> system within our USS subsystem.
>  
Looking earlier in this thread, it appears that it's IBM that wants you to 
GIMUNZIP.

I wonder why?  It seems circuitous.

But do they give you no alternative?

-- gil

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

ASMA032E Relocatable value or unresolved symbol found when absolute value required

[Charles Mills]

Why won't this assemble?

SOME  CSECT
  LLILF 2,FOO
OTHER CSECT
FOO   EQU   *

Why do I get ASMA032E Relocatable value or unresolved symbol found when
absolute value required - FOO?

Can't the assembler generate a relocatable address constant for the
immediate operand of LLILF? Or am I doing something stupid that I am not
seeing?

DC A(FOO) at the same spot assembles with no problem. I could presumably
code DC X'C02F',AL4(FOO) and it would execute correctly.

Charles 

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

Re: Problem with "RECEIVE" of z/OS 2.2 upgrade

[Paul Gilmartin]

On 2016-12-27 15:19, McCabe, Ron wrote:
> Yes, I need to GIMUNZIP.  All the files are in pax.z format on a ZFS file 
> system within our USS subsystem.
>  
That does not imply you need to GIMUNZIP.  RECEIVE FROMNTS should work for you.
That's what it's designed for.

I believe GIMUNZIP requires an elaborate control file which I have sometimes
generated by processing the GIMPAF/GIMFAF files in the archive.  But it's
the long way around.

-- gil

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

Re: Multi SRB

[Tony Harminc]

On 27 December 2016 at 16:32, Ed Jaffe  wrote:
> On 12/27/2016 1:13 PM, Joe Reichman wrote:
>>
>> Follow up question to my earlier post  can there be multiple SRB's
>> executing the same piece code  in the same address space
>
> Of course! There are two kinds of dispatchable units in MVS: TCBs and SRBs.

It's arguable that address spaces are dispatchable. But that perhaps
muddles the notions of dispatcher and scheduler (which these days is
really WLM).

Tony H.

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

Re: Multitasking question

[Ed Jaffe]

On 12/27/2016 4:08 PM, Charles Mills wrote:

Very cool!

Why copy? Why not use them where they are?


In some cases, they are programs whose instructions are dynamically 
altered as needed to conform to the needs of the customer's run-time 
environment. In other cases, they are objects with locally optimized 
code and embedded data areas. (DB2 does something quite similar.) For 
what we use them for, they are both very high-performing solutions...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Multitasking question

[Charles Mills]

Very cool!

Why copy? Why not use them where they are?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, December 27, 2016 11:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Multitasking question

On 12/27/2016 10:21 AM, Paul Gilmartin wrote:
>
> The address ranges wouldn't need to be identical if the code were 
> location independent.  This may have been a goal of the
> S/360 designers, never exploited in OS/360 software.

We exploit it all the time!

We have literally hundreds of programs with no RLD entries i.e., no embedded 
ADCONs. That makes it _really_ easy to copy them from one place to another via 
MVCLE and then pass control to them without having to worry about relocation.

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

Re: Multi SRB

[Charles Mills]

One has to get away from the notion of "an executing program": "where was
the program when it failed?" -- "right here, this line right here."

"A program" refers to two entirely independent things (on this or any other
modern platform):

a. A chunk of machine code sitting in memory.
b. A task or thread (TCB or SRB in MVS-speak). A logical string of
execution, accomplishing some logically connected work. 

For every (a.) there might be zero or more of (b.): resident code might have
no threads of execution currently using it, and it might have a dozen.

The above assumes "modern" reentrant code, standard on most platforms,
optional on z/OS. For non-reentrant code, a. and b. are pretty much
one-to-one.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joe Reichman
Sent: Tuesday, December 27, 2016 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Multi SRB

Hi

 

Follow up question to my earlier post  can there be multiple SRB's executing
the same piece code  in the same address space 

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

Re: Bad IOA card replaced, now test lpar Master console and alternate BOXED

[Jesse 1 Robinson]

If you are at the right OS level (2.1+), you can use either the classic 
Operating System Messages or the (finally supported!) HMC 3270 interface. We 
have been discussing eliminating all OSAC consoles from the NIP list and 
relying entirely on HMC. 

.
.
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 Edward Finnell
Sent: Tuesday, December 27, 2016 3:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Bad IOA card replaced, now test lpar Master console and 
alternate BOXED

You may use the HCD as a Consol?
 
Without looking in several years.
 
V CN(*),consol
ACTivate CN(*)
 
 
In a message dated 12/27/2016 5:26:06 P.M. Central Standard Time, 
johnmattson...@gmail.com writes:

And that  fixed everything.  Fortunately TSO was not affected, and so I could  
issue the commands from there.  I have never had the pleasure  of losing a 
Master Console before, and It was "exhillerating" even on a  test lpar.



--
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: Bad IOA card replaced, now test lpar Master console and alternate BOXED

[Edward Finnell]

You may use the HCD as a Consol?
 
Without looking in several years.
 
V CN(*),consol
ACTivate CN(*)
 
 
In a message dated 12/27/2016 5:26:06 P.M. Central Standard Time,  
johnmattson...@gmail.com writes:

And that  fixed everything.  Fortunately TSO was not affected, and so I
could  issue the commands from there.  I have never had the pleasure  of
losing a Master Console before, and It was "exhillerating" even on a  test
lpar.



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

Re: Bad IOA card replaced, now test lpar Master console and alternate BOXED

[John Mattson]

Indeed, Radoslaw, I should have put OSA card, and it was OSA C

Fortunately I had seen the likes of this before, but LONG LONG ago, and
after much flailing about I did the following:
#D M DEV and found which CHPID was offline,
#CF CHP(31),ONLINE  to config the chpid online
#V 5C1,ONLINE
#V 5C1,CONSOLE,AUTH=MASTER
And that fixed everything.  Fortunately TSO was not affected, and so I
could issue the commands from there.  I have never had the pleasure of
losing a Master Console before, and It was "exhillerating" even on a test
lpar.

Thanks much.

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

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[George, William@FTB]

Thanks and I've already rewritten it to use the CSI!  8-D

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Tuesday, December 27, 2016 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

> On Dec 27, 2016, at 10:59 AM, George, William@FTB  
> wrote:
> 
> I found parsing the LISTCAT output easy as I've done it many times and 
> much easier to understand.  8-D However. I just found the IBM REXX sample for 
> CSI and got it working.
> I'll copy the REXX I have using the LISTCAT code and change it to use CSI and 
> then compare the two.
> Thanks!
> 
> Bill

Bill,

Be aware that the list cat output *DOES* change and there is no warning from 
IBM.

Years ago someone bought a cheap listcat at a company I worked for (it was 
written in COBOL no less).
Once a year (or so it seemed) the utility would break. I would look at the 
source (they provided) and waste 1 or 2 hours of my time trying to debug it.
It was just not worth the $25.
Use the way Tom M suggested and it will eliminate 3AM calls.

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

__
CONFIDENTIALITY NOTICE: This email from the State of California is for the sole 
use of the intended recipient and may contain confidential and privileged 
information. Any unauthorized review or use, including disclosure or 
distribution, is prohibited. If you are not the intended recipient, please 
contact the sender and destroy all copies of this email.

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

Re: Looking for USERMOD samples

[Gerhard Adam]

What you have will look something like this:

//SMPCNTL  DD *
SET BDY(GLOBAL).
  RECEIVE SELECT(FMN2001) SYSMODS.
   SET BDY (TARGET).
   APPLY SELECT(FMN2001) RETRY(YES) REDO.
/*
//SMPPTFIN DD DATA,DLM=$$
++USERMOD (FMN2001) REWORK(201601) .
++VER (Z038) FMID(JADLD12) PRE(UI25246) .
++JCLIN.
//   EXEC  PGM=IEBCOPY
//DISTDD   DD  DSN=distribution library,DISP=SHR   [NOTE: make the DD
statement that on the DISTMOD parameter].
//TARGLIB  DD  DSN=target.library,DISP=SHR  [NOTE:  DD statement must
reflect target library]
//SYSIN  DD  *
   COPY OUTDD=TARGLIB,INDD=DISTDD
/*
++SRC(FMN2POPT) TXLIB(FMN2SRC) DISTLIB(AFMNSAM1) DISTMOD(distribution load
library).
   ***   Source code follows  ***

This should be all you need.  

Adam

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of R.S.
Sent: Tuesday, December 27, 2016 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for USERMOD samples

W dniu 2016-12-27 o 22:54, Paul Gilmartin pisze:
> On 2016-12-27 14:47, R.S. wrote:
>> I'm trying to learn a little bit about SMP/E usermods.
>> Unfortunately neither SMP/E manuals nor google did not provide good
(*well explained*) samples.
>>
>>
>> Example (from File Manager):
>> //SMPCNTL  DD *
>>   SET BDY(GLOBAL).
>>   RECEIVE SELECT(FMN2001) SYSMODS.
>>   SET BDY (TARGET).
>>   APPLY SELECT(FMN2001) RETRY(YES) REDO.
>> /*
>> //SMPPTFIN DD DATA,DLM=$$
>> ++USERMOD (FMN2001) REWORK(201601) .
>> ++VER (Z038) FMID(JADLD12) PRE(UI25246) .
>> ++JCLIN.
>> /*
>> ++SRC(FMN2POPT) TXLIB(FMN2SRC) DISTLIB(AFMNSAM1).
>> $$
>> FMN2SRC is a DD name pointing to a member with source code.
>> Q1: How can I know what's target library for the load module?
>> Q2: there is no assemble or linkedit jobstep. I assume it comes from
SMP/E.
>> Q3: FMN2SRC DD - should it describe library or member? In other words:
DSN=MY.LIB or DSN=MY.LIB(MEM) ?
>>
> A TXLIB is a library in which APPLY (I think) will save member FNM2POPT.
> With the options coded, the assembler source of FNM2POPT should appear 
> inline, after the ++SRC.  There are other ways; I'd need to RTFM to say
more.
>
> You'll need to allocate FNM2SRC in JCL and/or have a DDDEF for it.
>
TXLIB is a library with source code.
SMPE/ Reference: TXLIB  is the ddname of the partitioned data set containing
the source.
Similar description can be found in FMN.SFMNSAM1 (a source of the job quoted
above).
Although  the role of DISTLIB is not 100% clear for me, but definitely it's
not target library.


Regards
--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is
intended solely for business use of the addressee. This e-mail may only be
received by the addressee and may not be disclosed to any third parties. If
you are not the intended addressee of this e-mail or the employee authorized
to forward it to the addressee, be advised that any dissemination, copying,
distribution or any other similar activity is legally prohibited and may be
punishable. If you received this e-mail by mistake please advise the sender
immediately by using the reply facility in your e-mail software and delete
permanently this e-mail including any copies of it either printed or saved
to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości
wpłacony) wynosi 168.955.696 złotych.


--
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: Looking for USERMOD samples

[Gerhard Adam]

Look in the SMP/E Reference manual, in the section for ++SRC.   There are
some specific examples that will help.

Adam

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Tuesday, December 27, 2016 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for USERMOD samples

On 2016-12-27 14:47, R.S. wrote:
> I'm trying to learn a little bit about SMP/E usermods.
> Unfortunately neither SMP/E manuals nor google did not provide good (*well
explained*) samples.
> 
> 
> Example (from File Manager):
> //SMPCNTL  DD *
>  SET BDY(GLOBAL).
>  RECEIVE SELECT(FMN2001) SYSMODS.
>  SET BDY (TARGET).
>  APPLY SELECT(FMN2001) RETRY(YES) REDO.
> /*
> //SMPPTFIN DD DATA,DLM=$$
> ++USERMOD (FMN2001) REWORK(201601) .
> ++VER (Z038) FMID(JADLD12) PRE(UI25246) .
> ++JCLIN.
> /*
> ++SRC(FMN2POPT) TXLIB(FMN2SRC) DISTLIB(AFMNSAM1).
> $$
> FMN2SRC is a DD name pointing to a member with source code.
> Q1: How can I know what's target library for the load module?
> Q2: there is no assemble or linkedit jobstep. I assume it comes from
SMP/E.
> Q3: FMN2SRC DD - should it describe library or member? In other words:
DSN=MY.LIB or DSN=MY.LIB(MEM) ?
> 
A TXLIB is a library in which APPLY (I think) will save member FNM2POPT.
With the options coded, the assembler source of FNM2POPT should appear
inline, after the ++SRC.  There are other ways; I'd need to RTFM to say
more.

You'll need to allocate FNM2SRC in JCL and/or have a DDDEF for it.

-- 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: Looking for USERMOD samples

[Paul Gilmartin]

On 2016-12-27 15:09, R.S. wrote:
> W dniu 2016-12-27 o 22:54, Paul Gilmartin pisze:
>> On 2016-12-27 14:47, R.S. wrote:
>>> I'm trying to learn a little bit about SMP/E usermods.
>>> Unfortunately neither SMP/E manuals nor google did not provide good (*well 
>>> explained*) samples.
>>>
>>>
>>> Example (from File Manager):
>>> //SMPCNTL  DD *
>>>   SET BDY(GLOBAL).
>>>   RECEIVE SELECT(FMN2001) SYSMODS.
>>>   SET BDY (TARGET).
>>>   APPLY SELECT(FMN2001) RETRY(YES) REDO.
>>> /*
>>> //SMPPTFIN DD DATA,DLM=$$
>>> ++USERMOD (FMN2001) REWORK(201601) .
>>> ++VER (Z038) FMID(JADLD12) PRE(UI25246) .
>>> ++JCLIN.
>>> /*
>>> ++SRC(FMN2POPT) TXLIB(FMN2SRC) DISTLIB(AFMNSAM1).
>>> $$
>>> FMN2SRC is a DD name pointing to a member with source code.
>>> Q1: How can I know what's target library for the load module?
>>>
++JCLIN should contain
//SYSLIN
  INCLUDE (FMN2POPT)
  NAME FMN2LMOD(R)
//SYSLMOD  DD  DSN=no.matter.TLIB
... where the rightmost qualifier of the SYSLMOD DSN identifies the DDDEF
name in the target zone of the load module library.  This might be
overridden in the APPLY step with:
//TLIB  DD ...  (But don't do that.)

>>> Q2: there is no assemble or linkedit jobstep. I assume it comes from SMP/E.
>>>
It should appear in ++JCLIN, which isn't really JCL even though it looks
like it.  ++JCLIN creates entries in the SMP/E VSAM data base which are
used by APPLY and ACCEPT.

>>> Q3: FMN2SRC DD - should it describe library or member? In other words: 
>>> DSN=MY.LIB or DSN=MY.LIB(MEM) ?
>>>
>> A TXLIB is a library in which APPLY (I think) will save member FNM2POPT.
>> With the options coded, the assembler source of FNM2POPT should appear 
>> inline,
>> after the ++SRC.  There are other ways; I'd need to RTFM to say more.
>>
>> You'll need to allocate FNM2SRC in JCL and/or have a DDDEF for it.
>>
> TXLIB is a library with source code.
> SMPE/ Reference: TXLIB  is the ddname of the partitioned data set containing 
> the source.
>
I'll stand corrected.  The value, FMN2SRC of the TXLIB key identifies either 
the DDNAME
or the DDDEF entry of the library containing the source member (FMN2OPT)

> Similar description can be found in FMN.SFMNSAM1 (a source of the job quoted 
> above).
> Although  the role of DISTLIB is not 100% clear for me, but definitely it's 
> not target library.
> 
Yes, there are distribution libraries for both the source and the assembled
object which are updated by ACCEPT.  Most programmers don't ACCEPT USERMODs.

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

Re: Addressing Question

[Bill Woodger]

Thanks. I think you are probably "getting away with it". Since you are not 
using any data from a COBOL program, that DATA(31) is not an issue. I suspect 
in your bindered program, the COBOL programs are always "below the line", so 
the return-address is not getting accidentally truncated. I think if you were 
to what a 16MB table into the initial COBOL program that the binder would 
complain. If not, you'd get a run-time problem of some type. 

I guess we'd need to see the binder output to confirm.

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

Re: Problem with "RECEIVE" of z/OS 2.2 upgrade

[McCabe, Ron]

Yes, I need to GIMUNZIP.  All the files are in pax.z format on a ZFS file 
system within our USS subsystem.

Thanks,
Ron McCabe
Mutual of Enumclaw


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 27, 2016 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problem with "RECEIVE" of z/OS 2.2 upgrade

On 2016-12-27 14:54, McCabe, Ron wrote:
> It is GIMUNZIP.
>
I believe (I'm not looking) we have GIMUNZIP program object in SYS1.MIGLIB 
which is in LINKLIST.  JCL might come with RECEIVE ORDER (I haven't done that).

Do you need to GIMUNZIP rather than simply RECEIVE ORDER/FROMNETWORK/FROMNTS/

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

Re: Bad IOA card replaced, now test lpar Master console and alternate BOXED

[R.S.]

W dniu 2016-12-27 o 22:59, John Mattson pisze:

So IBM replaced a bad IOA card.  Now the test lpar has both consoles
BOXED.  Messy to say the least.  Nothing I have been able to do has brought
them back online, not VARY ONLINE or VARY CONSOLE.  Says no paths
available.  LPAR is still up, but we have to get out of this.
My first impulse was to IPL the TEST LPAR, but we need the MCONS to IPL.
and if it does not come up I would seem to be in a bit of a bind.
 Anyone have any suggestions?


Do you mean OSA card?
Was the chpid defined as OSC?
Did you recreate ICC session definitions?

--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: Looking for USERMOD samples

[R.S.]

W dniu 2016-12-27 o 22:54, Paul Gilmartin pisze:

On 2016-12-27 14:47, R.S. wrote:

I'm trying to learn a little bit about SMP/E usermods.
Unfortunately neither SMP/E manuals nor google did not provide good (*well 
explained*) samples.


Example (from File Manager):
//SMPCNTL  DD *
  SET BDY(GLOBAL).
  RECEIVE SELECT(FMN2001) SYSMODS.
  SET BDY (TARGET).
  APPLY SELECT(FMN2001) RETRY(YES) REDO.
/*
//SMPPTFIN DD DATA,DLM=$$
++USERMOD (FMN2001) REWORK(201601) .
++VER (Z038) FMID(JADLD12) PRE(UI25246) .
++JCLIN.
/*
++SRC(FMN2POPT) TXLIB(FMN2SRC) DISTLIB(AFMNSAM1).
$$
FMN2SRC is a DD name pointing to a member with source code.
Q1: How can I know what's target library for the load module?
Q2: there is no assemble or linkedit jobstep. I assume it comes from SMP/E.
Q3: FMN2SRC DD - should it describe library or member? In other words: 
DSN=MY.LIB or DSN=MY.LIB(MEM) ?


A TXLIB is a library in which APPLY (I think) will save member FNM2POPT.
With the options coded, the assembler source of FNM2POPT should appear inline,
after the ++SRC.  There are other ways; I'd need to RTFM to say more.

You'll need to allocate FNM2SRC in JCL and/or have a DDDEF for it.


TXLIB is a library with source code.
SMPE/ Reference: TXLIB  is the ddname of the partitioned data set 
containing the source.
Similar description can be found in FMN.SFMNSAM1 (a source of the job 
quoted above).
Although  the role of DISTLIB is not 100% clear for me, but definitely 
it's not target library.



Regards
--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Bad IOA card replaced, now test lpar Master console and alternate BOXED

[John Mattson]

So IBM replaced a bad IOA card.  Now the test lpar has both consoles
BOXED.  Messy to say the least.  Nothing I have been able to do has brought
them back online, not VARY ONLINE or VARY CONSOLE.  Says no paths
available.  LPAR is still up, but we have to get out of this.
My first impulse was to IPL the TEST LPAR, but we need the MCONS to IPL.
and if it does not come up I would seem to be in a bit of a bind.
Anyone have any suggestions?

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

Re: Problem with "RECEIVE" of z/OS 2.2 upgrade

[Paul Gilmartin]

On 2016-12-27 14:54, McCabe, Ron wrote:
> It is GIMUNZIP.
> 
I believe (I'm not looking) we have GIMUNZIP program object in
SYS1.MIGLIB which is in LINKLIST.  JCL might come with RECEIVE ORDER
(I haven't done that).

Do you need to GIMUNZIP rather than simply RECEIVE ORDER/FROMNETWORK/FROMNTS/

-- gil

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

Re: Problem with "RECEIVE" of z/OS 2.2 upgrade

[McCabe, Ron]

It is GIMUNZIP.

Thanks,
Ron McCabe
Mutual of Enumclaw


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 27, 2016 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problem with "RECEIVE" of z/OS 2.2 upgrade

On 2016-12-27 14:44, McCabe, Ron wrote:
> Hello,
>
> Sorry I didn't respond earlier but we got a few extra days off for Christmas 
> and then I will be taking some time off for the New Year.  I'm still working 
> this problem.
>
> I don't have an UNZIP JCL in any of the 2 subdirectories that I downloaded.  
> Our IBM business partner created the order and then I downloaded it to our 
> mainframe when it was ready.  There were 2 subdirectories for the order...an 
> ORDER sub directory and a CONTENT sub directory.  I was able to update our 
> CustomPac Dialog successfully with what was in the ORDER subdirectory using 
> the EUPDATES job that was provided in the documentation for our order.
>
> So now I'm doing the first step in the Dialog which is to receive the order.  
> It creates a JCL for me which has the UNZIP in it.  I need to take a closer 
> look at the JCL that was created because it must be pointing at wrong 
> datasets somewhere.  More to come later.
>
Is that UNZIP or GIMUNZIP?  If GIMUNZUP, you should have it.  If UNZIP, you 
might substitute "jar", whose options are unlike those for UNZIP but like those 
for "tar".

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

Re: Looking for USERMOD samples

[Paul Gilmartin]

On 2016-12-27 14:47, R.S. wrote:
> I'm trying to learn a little bit about SMP/E usermods.
> Unfortunately neither SMP/E manuals nor google did not provide good (*well 
> explained*) samples.
> 
> 
> Example (from File Manager):
> //SMPCNTL  DD *
>  SET BDY(GLOBAL).
>  RECEIVE SELECT(FMN2001) SYSMODS.
>  SET BDY (TARGET).
>  APPLY SELECT(FMN2001) RETRY(YES) REDO.
> /*
> //SMPPTFIN DD DATA,DLM=$$
> ++USERMOD (FMN2001) REWORK(201601) .
> ++VER (Z038) FMID(JADLD12) PRE(UI25246) .
> ++JCLIN.
> /*
> ++SRC(FMN2POPT) TXLIB(FMN2SRC) DISTLIB(AFMNSAM1).
> $$
> FMN2SRC is a DD name pointing to a member with source code.
> Q1: How can I know what's target library for the load module?
> Q2: there is no assemble or linkedit jobstep. I assume it comes from SMP/E.
> Q3: FMN2SRC DD - should it describe library or member? In other words: 
> DSN=MY.LIB or DSN=MY.LIB(MEM) ?
> 
A TXLIB is a library in which APPLY (I think) will save member FNM2POPT.
With the options coded, the assembler source of FNM2POPT should appear inline,
after the ++SRC.  There are other ways; I'd need to RTFM to say more.

You'll need to allocate FNM2SRC in JCL and/or have a DDDEF for it.

-- gil

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

Looking for USERMOD samples

[R.S.]

I'm trying to learn a little bit about SMP/E usermods.
Unfortunately neither SMP/E manuals nor google did not provide good 
(*well explained*) samples.



Example (from File Manager):
//SMPCNTL  DD *
 SET BDY(GLOBAL).
 RECEIVE SELECT(FMN2001) SYSMODS.
 SET BDY (TARGET).
 APPLY SELECT(FMN2001) RETRY(YES) REDO.
/*
//SMPPTFIN DD DATA,DLM=$$
++USERMOD (FMN2001) REWORK(201601) .
++VER (Z038) FMID(JADLD12) PRE(UI25246) .
++JCLIN.
/*
++SRC(FMN2POPT) TXLIB(FMN2SRC) DISTLIB(AFMNSAM1).
$$
FMN2SRC is a DD name pointing to a member with source code.
Q1: How can I know what's target library for the load module?
Q2: there is no assemble or linkedit jobstep. I assume it comes from SMP/E.
Q3: FMN2SRC DD - should it describe library or member? In other words: 
DSN=MY.LIB or DSN=MY.LIB(MEM) ?






--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: Problem with "RECEIVE" of z/OS 2.2 upgrade

[Paul Gilmartin]

On 2016-12-27 14:44, McCabe, Ron wrote:
> Hello,
> 
> Sorry I didn't respond earlier but we got a few extra days off for Christmas 
> and then I will be taking some time off for the New Year.  I'm still working 
> this problem.
> 
> I don't have an UNZIP JCL in any of the 2 subdirectories that I downloaded.  
> Our IBM business partner created the order and then I downloaded it to our 
> mainframe when it was ready.  There were 2 subdirectories for the order...an 
> ORDER sub directory and a CONTENT sub directory.  I was able to update our 
> CustomPac Dialog successfully with what was in the ORDER subdirectory using 
> the EUPDATES job that was provided in the documentation for our order.
> 
> So now I'm doing the first step in the Dialog which is to receive the order.  
> It creates a JCL for me which has the UNZIP in it.  I need to take a closer 
> look at the JCL that was created because it must be pointing at wrong 
> datasets somewhere.  More to come later.
>  
Is that UNZIP or GIMUNZIP?  If GIMUNZUP, you should have it.  If UNZIP,
you might substitute "jar", whose options are unlike those for UNZIP but
like those for "tar".

-- gil

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

Re: Problem with "RECEIVE" of z/OS 2.2 upgrade

[McCabe, Ron]

Hello,

Sorry I didn't respond earlier but we got a few extra days off for Christmas 
and then I will be taking some time off for the New Year.  I'm still working 
this problem.

I don't have an UNZIP JCL in any of the 2 subdirectories that I downloaded.  
Our IBM business partner created the order and then I downloaded it to our 
mainframe when it was ready.  There were 2 subdirectories for the order...an 
ORDER sub directory and a CONTENT sub directory.  I was able to update our 
CustomPac Dialog successfully with what was in the ORDER subdirectory using the 
EUPDATES job that was provided in the documentation for our order.

So now I'm doing the first step in the Dialog which is to receive the order.  
It creates a JCL for me which has the UNZIP in it.  I need to take a closer 
look at the JCL that was created because it must be pointing at wrong datasets 
somewhere.  More to come later.

Thanks,
Ron McCabe
Mutual of Enumclaw

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Bickerdike
Sent: Friday, December 23, 2016 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problem with "RECEIVE" of z/OS 2.2 upgrade

When the UNZIPJCL is executed, it goes to the GIMPAF.XML file within the same 
subdirectory, and uses the description there to try to resolve the file name to 
the actual file within the subdirectory. The error message indicates that no 
such file exists within the install subdirectory.

This is caused by running the UNZIPJCL file from the wrong subdirectory; 
usually one for a previous install. To resolve this error, simply find the 
UNZIPJCL file from the correct subdirectory (the one for this install) and run 
that JCL. This will reference the corresponding GIMPAF.XML file, which contains 
the correct file name for this install; this will resolve the error.

On Fri, Dec 23, 2016 at 10:05 AM, McCabe, Ron 
wrote:

> Hello List,
>
> I know that everyone is either off or about to be off to enjoy the
> holidays but I thought I would throw this question out anyway so
> hopefully I will be that much closer to resolving my problem.
>
> I have downloaded z/OS 2.2 upgrade and the first step in the dialog is
> to "receive" the order.  In the UNZIP step which executes GIMUNZIP I
> get the following error:
>
> GIM48900S ** THE PACKAGE ATTRIBUTE FILE DOES NOT CONTAIN AN ENTRY FOR
> REQUIRED A RCHIVE DOCLIB.
>
> From everything I have checked out I have everything that is needed.
> Has anyone else run into this problem?  Any help as to how I can get
> this resolved (I do already have a PMR opened so no need to mention
> that)?  We are running z/OS 1.13 which is an eligible driving system to 
> install 2.2.
>
> Thanks,
> Ron McCabe
> Mutual of Enumclaw
>
>
> Confidentiality Notice: This e- mail and all attachments may contain
> CONFIDENTIAL information and are meant solely for the intended recipient.
> It may contain controlled, privileged, or proprietary information that
> is protected under applicable law and shall not be disclosed to any
> unauthorized third party. If you are not the intended recipient, you
> are hereby notified that any unauthorized review, action, disclosure,
> distribution, or reproduction of any information contained in this e-
> mail and any attachments is strictly PROHIBITED. If you received this
> e- mail in error, please reply to the sender immediately stating that
> this transmission was misdirected, and delete or destroy all
> electronic and paper copies of this e-mail and attachments without
> disclosing the contents. This e- mail does not grant or assign rights
> of ownership in the proprietary subject matter herein, nor shall it be
> construed as a joint venture, partnership, teaming agreement, or any
> other formal business relationship.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic 

Re: stop responding

[retired mainframer]

If people want to complain to various service providers, that's fine.  But 
there is no reason to CC the list with the complaint and there is no reason to 
respond to the rantings in the list.  If you really have to tell him how stupid 
he is, do it directly.  In the interim, kill filters will not stop him from 
posting but they will prevent us from seeing his posts.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jim Carpenter
Sent: Tuesday, December 27, 2016 11:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: stop responding

People need to start complaining to Google, GoDaddy, etc. and get his
accounts and domains suspended. Make it too expensive in time/money
and _maybe_ he'll go away.

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

Re: Multi SRB

[Paul Gilmartin]

On Tue, 27 Dec 2016 16:13:33 -0500, Joe Reichman wrote:
>
>Follow up question to my earlier post  can there be multiple SRB's executing
>the same piece code  in the same address space
> 
My guess would be yes, if the Program Object is marked REFR and loaded
under different TCBs in the same address space or comes from LPA.

Or, if you LOAD it and branch to it from multiple TCBs.  Integrity is left as
an exercise for the student.

-- gil

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

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Edward Gould]

> On Dec 27, 2016, at 10:59 AM, George, William@FTB  
> wrote:
> 
> I found parsing the LISTCAT output easy as I've done it many times and much 
> easier to understand.  8-D
> However. I just found the IBM REXX sample for CSI and got it working.
> I'll copy the REXX I have using the LISTCAT code and change it to use CSI and 
> then compare the two.
> Thanks!
> 
> Bill

Bill,

Be aware that the list cat output *DOES* change and there is no warning from 
IBM.

Years ago someone bought a cheap listcat at a company I worked for (it was 
written in COBOL no less).
Once a year (or so it seemed) the utility would break. I would look at the 
source (they provided) and waste 1 or 2 hours of my time trying to debug it.
It was just not worth the $25.
Use the way Tom M suggested and it will eliminate 3AM calls.

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

Re: Multi SRB

[Ed Jaffe]

On 12/27/2016 1:13 PM, Joe Reichman wrote:

Follow up question to my earlier post  can there be multiple SRB's executing
the same piece code  in the same address space


Of course! There are two kinds of dispatchable units in MVS: TCBs and SRBs.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Multi SRB

[Joe Reichman]

Hi

 

Follow up question to my earlier post  can there be multiple SRB's executing
the same piece code  in the same address space 


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

Re: Multitasking question

[Paul Gilmartin]

On Tue, 27 Dec 2016 11:01:29 -0800, Ed Jaffe wrote:
>
>We have literally hundreds of programs with no RLD entries i.e., no
>embedded ADCONs. That makes it _really_ easy to copy them from one place
>to another via MVCLE and then pass control to them without having to
>worry about relocation.
>
Decades ago, I had experimented with similar techniques, even so far as
paired +- RLDs.  In the course of that, I discovered that CMS obeys its
own rules.  If I had unresolved WXTRN + absolute offset, it got relocated
anyway because CMS assumed the nonzero result meant the WXTRN was
resolved.

-- gil

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

Re: stop responding

[David Cole]

Yours is a self-fulfilling, Jim.

On Dec 27, 2016 2:24 PM, "Jim Carpenter"  wrote:

> Ignoring spammers doesn't really work, especially in this case. This
> is not your standard drive-by spammer. This loon is targeting the list
> and its members. Ignore him and soon you'll see a dozen spams a day
> from him using various e-mail addresses. He told me the other day that
> when he spammed the list he thought that nobody had received it, so he
> started spamming members directly. This is someone that will do
> anything to force us to see his message, whatever the hell it is.
> Ignoring him won't be possible and your delete key and spam filters
> aren't going to be enough.
>
> People need to start complaining to Google, GoDaddy, etc. and get his
> accounts and domains suspended. Make it too expensive in time/money
> and _maybe_ he'll go away.
>
> Jim
>
>
> On Tue, Dec 27, 2016 at 5:58 AM, David Cole  wrote:
> > Absolutely! Just stop responding.
> >
> > If you stop rising to his bait, he will no longer matter!
> > Just ignore him. if he doesn't go away, at least he will become
> irrelevant.
> >
> > After all, how hard is it to add him to your SPAM filters?
> > For that matter, how hard is it to press DELETE?
> > Or to simply ignore his posts and move on with your lives?
>
> --
> 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: stop responding

[Jim Carpenter]

Ignoring spammers doesn't really work, especially in this case. This
is not your standard drive-by spammer. This loon is targeting the list
and its members. Ignore him and soon you'll see a dozen spams a day
from him using various e-mail addresses. He told me the other day that
when he spammed the list he thought that nobody had received it, so he
started spamming members directly. This is someone that will do
anything to force us to see his message, whatever the hell it is.
Ignoring him won't be possible and your delete key and spam filters
aren't going to be enough.

People need to start complaining to Google, GoDaddy, etc. and get his
accounts and domains suspended. Make it too expensive in time/money
and _maybe_ he'll go away.

Jim


On Tue, Dec 27, 2016 at 5:58 AM, David Cole  wrote:
> Absolutely! Just stop responding.
>
> If you stop rising to his bait, he will no longer matter!
> Just ignore him. if he doesn't go away, at least he will become irrelevant.
>
> After all, how hard is it to add him to your SPAM filters?
> For that matter, how hard is it to press DELETE?
> Or to simply ignore his posts and move on with your lives?

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

Re: Multitasking question

[Ed Jaffe]

On 12/27/2016 10:21 AM, Paul Gilmartin wrote:


The address ranges wouldn't need to be identical if the code
were location independent.  This may have been a goal of the
S/360 designers, never exploited in OS/360 software.


We exploit it all the time!

We have literally hundreds of programs with no RLD entries i.e., no 
embedded ADCONs. That makes it _really_ easy to copy them from one place 
to another via MVCLE and then pass control to them without having to 
worry about relocation.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Multitasking question

[Anne & Lynn Wheeler]

000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes:
> Further, with UNIX shared memory and the older CSA and LPA
> a single page, possibly executable, can be mapped into multiple
> address spaces.  It better be reentrant.
>
> The address ranges wouldn't need to be identical if the code
> were location independent.  This may have been a goal of the
> S/360 designers, never exploited in OS/360 software.

os/360 relocation adcons became fixed when executable was loaded into
storage before execution.

tss/360 did implement location independent executable images (where same
image could be mapped simultaneously into different virtual address
spaces at different locations.

when i did page-mapped filesystem for (cp67/)cms in the early 70s, I
also implemented location independent support ... but CMS primarily used
OS/360 assembler/compile/loader conventions (with relocatable adcons
that got fixed at load time, rather than the tss/360 model) ... I
frequently had to significantly massage os/360 "generated" code to make
it location independent. I then ported the support to vm370/cms ... and
a very small subset was included in vm370 release 3, w/o the paged map
filesystem and the location independent support.

past posts mentioning horrible contortions I sometimes had to resort
to in order to have location independent code.
http://www.garlic.com/~lynn/submain.html#adcon

I would say that when I did the CMS page-mapped filesystem ... I avoided
doing all the things that I saw tss/360 had done wrong (from performance
stand point, it did do the location independent correctly). Possibly one
of the reasons that the full page-mapped stuff wasn't included in vm370
release 3 was because the (failed) FS effort had pretty much adopted the
tss/360 model ... and "page-mapped" got such a bad reputation with
the FS failure ... some past posts
http://www.garlic.com/~lynn/submain.html#futuresys

even tho I could show my cms page-mapped filesystem had 3-4 times the
throughput of the native cms filesystem (both original and EDF). some
past filesystem
http://www.garlic.com/~lynn/submain.html#mmap

other trivia, something similar also shows up at the time of decision to
migrate all 370 to virtual memory ... recent post mentioning major
motivation was the horrible MVT storage management.
http://www.garlic.com/~lynn/2016h.html#98 A Christmassy PL/I tale

Simpson (from HASP), rather than going to gburg as part of HASP/JES
group ... went to Hawthorne and did "RASP" ... a MFT2 based
implementation supporting an (os/360 oriented) paged-map filesystem
... which showed some of the advantages for (os/360 based) virtual
memory systems.

When it wasn't picked up, he left IBM and joined a clone processor maker
... where he re-implemented RASP from scratch.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Addressing Question

[scott Ford]

Bill,

Data is not shared, the called assembler routines in question perform
extracts from a DB output to a file. Then the assembler routine returns.
Peter was kind enough to answe my question. We run DATA(31) ALL31(ON) and
of course routines have been working for a long time.

Scott

On Tuesday, December 27, 2016, Bill Woodger  wrote:

> What is the value of the Language Environment option ALL31? With
> ALL31(OFF), an LE run-time routine will deal with AMODE switching between
> CALLs.
>
> If any of the Assembler programs are accessing data from the COBOL
> programs, those COBOL programs should be DATA(24) (you claim DATA(31).
>
> Can you be explicit about what you mean by "self-contained"? If the
> Assembler programs are CALLed with no parameters and, for instance, just
> start up some type of service, then, as long as the Assembler program
> doesn't get to garble the return-address, you can ignore any interaction
> between COBOL and Asm. Is that what you have? If not, please describe it
> more clearly, including answers to the questions previously asked.
>
> All you CALLs are static, then we'd just absolutely love to see your
> output from the binder. Perhaps after answers to the above.
>
>
>
> --
> 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: Multitasking question

[Ed Jaffe]

On 12/27/2016 10:24 AM, Joseph Reichman wrote:

It's misleading the unit of work is really the RB


Not when "unit of work" is used as a synonym for "dispatchable unit".

An RB is not a unit of work. It's really just a glorified save area chain.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Multitasking question

[Joseph Reichman]

It's misleading the unit of work is really the RB

One more somewhat pertinent question in a address space if the unit of work is 
a SRB that address is ASCBSAWQ 




> On Dec 27, 2016, at 12:57 PM, Ed Jaffe  wrote:
> 
>> On 12/27/2016 9:51 AM, Joe Reichman wrote:
>> That term is okay the issue I have is with the term Multitasking is 
>> MultiRBing
> 
> There is no such term as MultiRBing.
> 
> When multitasking, each TCB represents an independent, asynchronous unit of 
> work to the MVS dispatcher.
> 
> RBs merely represent a form of procedural call stacking, implemented in 
> software, within a single TCB.
> 
> -- 
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
> 
> --
> 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: Multitasking question

[Paul Gilmartin]

On Tue, 27 Dec 2016 09:48:59 -0800, Ed Jaffe wrote:

>On 12/27/2016 9:41 AM, Joe Reichman wrote:
>> The RB's associated with the task/TCB differentiate the programs but the
>> code can live in same private address - range
>>
>> Correct ?
>
>Yes. That is essentially the definition of reentrant code.
> 
Further, with UNIX shared memory and the older CSA and LPA
a single page, possibly executable, can be mapped into multiple
address spaces.  It better be reentrant.

The address ranges wouldn't need to be identical if the code
were location independent.  This may have been a goal of the
S/360 designers, never exploited in OS/360 software.

-- gil

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

Re: Multitasking question

[John McKown]

On Tue, Dec 27, 2016 at 11:41 AM, Joe Reichman 
wrote:

> Hi
>
> Unlike other programming platforms where a program is associated with a
> thread or in z/os jargon Task
>
> There can be number of programs running in the same private address space
> under one Task aka TCB
>

​Well, there is only a single "thread of execution" under a single TCB.
I.e. you can't dispatch two RBs in a TCB concurrently.​ But you can "stack"
programs where program A can invoke program B which can then return back to
the original program. This to basically any depth. This is what the LINK
SVC does.


>
> The RB's associated with the task/TCB differentiate the programs but the
> code can live in same private address - range
>

​If I understand you, this is correct.​


>
> Correct ?
>

​I think what you have said is correct. I am not very Windows literate, but
do know UNIX some. I do not think that a Windows ".exe" program can run
another arbitrary ​".exe" as a general subroutine, in the same address
space. The same with Linux. A Windows program can use "subroutines" which
are dynamically loaded from a DLL. Linux has the equivalent with a "shared
object".

-- 
Heisenberg may have been here.

http://xkcd.com/1770/

Maranatha! <><
John McKown

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

Re: Multitasking question

[Ed Jaffe]

On 12/27/2016 9:51 AM, Joe Reichman wrote:

That term is okay the issue I have is with the term Multitasking is MultiRBing


There is no such term as MultiRBing.

When multitasking, each TCB represents an independent, asynchronous unit 
of work to the MVS dispatcher.


RBs merely represent a form of procedural call stacking, implemented in 
software, within a single TCB.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Multitasking question

[Joe Reichman]

Ed,

That term is okay the issue I have is with the term Multitasking is MultiRBing  
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, December 27, 2016 12:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Multitasking question

On 12/27/2016 9:41 AM, Joe Reichman wrote:
> The RB's associated with the task/TCB differentiate the programs but 
> the code can live in same private address - range
>
> Correct ?

Yes. That is essentially the definition of reentrant code.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
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: Multitasking question

[Ed Jaffe]

On 12/27/2016 9:41 AM, Joe Reichman wrote:

The RB's associated with the task/TCB differentiate the programs but the
code can live in same private address - range

Correct ?


Yes. That is essentially the definition of reentrant code.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Multitasking question

[Joe Reichman]

Hi

 

Unlike other programming platforms where a program is associated with a
thread or in z/os jargon Task

 

There can be number of programs running in the same private address space
under one Task aka TCB

 

The RB's associated with the task/TCB differentiate the programs but the
code can live in same private address - range

 

Correct ?   


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

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Dana Mitchell]

Yes there's an excellent REXX example in SYS1.SAMPLIB(IGGCSIRX) that can easily 
be modified to do all sorts of cool things (along with a few assembler samples 
too).

Dana

On Tue, 27 Dec 2016 16:59:08 +, George, William@FTB 
 wrote:
 
However. I just found the IBM REXX sample for CSI and got it working. 


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

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Bill Woodger]

As came up in a recent discussion here (Lizette's small COBOL program thing), 
IBM's recommendation is to use CSI over parsing LISTCAT. LISTCAT output is, and 
has been for a while, open to change, even a breaking change, and we've been 
warned.

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

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[George, William@FTB]

I found parsing the LISTCAT output easy as I've done it many times and much 
easier to understand.  8-D
However. I just found the IBM REXX sample for CSI and got it working.
I'll copy the REXX I have using the LISTCAT code and change it to use CSI and 
then compare the two.
Thanks!

Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, December 27, 2016 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

On Tue, 27 Dec 2016 16:30:32 +, George, William@FTB wrote about IGGCSI00:

>I've never had success trying it. The one example I have I could not 
>get to work but it has been a couple of years since then.

I've only used it once, and don't remember having any trouble with it. 
Certainly easier than parsing LISTCAT output.

--
Tom Marchant

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

__
CONFIDENTIALITY NOTICE: This email from the State of California is for the sole 
use of the intended recipient and may contain confidential and privileged 
information. Any unauthorized review or use, including disclosure or 
distribution, is prohibited. If you are not the intended recipient, please 
contact the sender and destroy all copies of this email.


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

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Tom Marchant]

On Tue, 27 Dec 2016 16:30:32 +, George, William@FTB wrote 
about IGGCSI00:

>I've never had success trying it. The one example I have I could 
>not get to work but it has been a couple of years since then. 

I've only used it once, and don't remember having any trouble with it. 
Certainly easier than parsing LISTCAT output.

-- 
Tom Marchant

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

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[George, William@FTB]

I've never had success trying it. The one example I have I could not get to 
work but it has been a couple of years since then. 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, December 27, 2016 6:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

On Tue, 20 Dec 2016 12:25:30 -0700, Sri h Kolusu wrote:

>Step 1 : Get Listcat information for the GDG Base Step 2 : parse the 
>Listcat information for the migrated generations and

Why not use the Catalog Search Interface (IGGCSI00) rather than parse a LISTCAT 
report? It is easier and more efficient.

--
Tom Marchant

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

__
CONFIDENTIALITY NOTICE: This email from the State of California is for the sole 
use of the intended recipient and may contain confidential and privileged 
information. Any unauthorized review or use, including disclosure or 
distribution, is prohibited. If you are not the intended recipient, please 
contact the sender and destroy all copies of this email.


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

Re: Addressing Question

[Bill Woodger]

What is the value of the Language Environment option ALL31? With ALL31(OFF), an 
LE run-time routine will deal with AMODE switching between CALLs.

If any of the Assembler programs are accessing data from the COBOL programs, 
those COBOL programs should be DATA(24) (you claim DATA(31).

Can you be explicit about what you mean by "self-contained"? If the Assembler 
programs are CALLed with no parameters and, for instance, just start up some 
type of service, then, as long as the Assembler program doesn't get to garble 
the return-address, you can ignore any interaction between COBOL and Asm. Is 
that what you have? If not, please describe it more clearly, including answers 
to the questions previously asked.

All you CALLs are static, then we'd just absolutely love to see your output 
from the binder. Perhaps after answers to the above.



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

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Tom Marchant]

On Tue, 20 Dec 2016 12:25:30 -0700, Sri h Kolusu wrote:

>Step 1 : Get Listcat information for the GDG Base
>Step 2 : parse the Listcat information for the migrated generations and 

Why not use the Catalog Search Interface (IGGCSI00) rather than 
parse a LISTCAT report? It is easier and more efficient.

-- 
Tom Marchant

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

Re: stop responding

[Adam Marshall Dobrin]

I couldn't agree more.  If you aren't interestested in a conversation that
you overhear, say at the water cooler--go back to your desk and do some
work.  There's no reason to sit around complaing over and over again about
the guy that just wouldn't shut up about the amazintg dream he had.  I
think social conventions are being completely destroyed here on the
intrernet--where some people think it's OK to walk around putting gags on
other people... to jump in between a conversation and stick cotton balls in
the ears of ABSOLUTELY EVERYONE ELSE AROUND THEM.  There's three people
here, telling everyone else they cannot listen to the guy that is telling
the world Heaven and virtual reality are like ... Jesus and Lucifer.
Nearly identical in form... yet there's a significant difference: Jesus is
firghting for freedom.

That being said, it's been happening for a long, long time--this digression
and social slide into a place where "free speech" just doesn't mean "free
speech" on the internet.  Here, to get new an unheaard information out, you
have to rely in ads (which costs lots of money) or social media.  That
would be a good answer, and this stuff is INDENCIDARY, it should spread
like wild-fire, and that spreading is the reason ther's a fire at the
Burning Bush, at the Holy Sepulcher, and that's the reason Judaism has an
Eternal Flame.  That's LIFE in the Universe, lasting eternally because of
this event.

All aside right now, because this fire doesn't spread--proof of time
travel--doesn't spread like wildfire on Facebook and reddit and Twitter.  I
know it's because of a censorwall--not because all of a sudden the
mysteries of religion are passe, and science fiction meets time travel
meets the time traveler doesn't pique anyone's interest.  I know it because
I've seen it, because this message is the glowing symbol to the worl dthat
CARNIVORE is infact EATING PACKETS.  Listen carefully, because this really
is the Second Coming, and it's really designed to build Heaven... by
destroying CENSORSHIP.  Among other things.

Aptly named?

Since this is IT group, I'm sure you are aware of CARINVORE, this illegal
and unconstitutional program the government says is a PACKET SNIFFER.  I'm
also sure you know what EATING PACKETS means to FREE SPEECH.

More?  Exodus is called the BOOK OF NAMES in Hebrew, and in Genesis ADAM
named all the things around him.  I haven't named anything here, but I can
read meaning in everything I see.  NAMES like SNOWDEN and WARDEN invite me
to introduce you to the FOR BIDding on this DEN KNOWLEDGE of EDEN.

Dave Matthews sings there's Snow Outside our Ark--icy tears of lamentaiton
that we are still stuck fighting for freedom in a place where it's so
easily attainable.

A place filled with family, rather than being gyped or a kingdom with a
hidden king... AN: no dom in I; Between the E's, Eden, Edom, and Egypt...
understand we are leaving the place of hidden slavery, because of a hidden
king who wants nothing more than to have a very large unhidden family.

Peace be with you.
ᐧ

On Tue, Dec 27, 2016 at 5:58 AM, David Cole  wrote:

> Absolutely! Just stop responding.
>
> If you stop rising to his bait, he will no longer matter!
> Just ignore him. if he doesn't go away, at least he will become irrelevant.
>
> After all, how hard is it to add him to your SPAM filters?
> For that matter, how hard is it to press DELETE?
> Or to simply ignore his posts and move on with your lives?
>
> Dave Cole
> ColeSoft Marketing
> 414 Third Street, NE
> Charlottesville, VA 22902
> EADDRESS:dbc...@colesoft.com
>
> Home page:   www.colesoft.com
> LinkedIn:www.xdc.com
> Facebook:www.facebook.com/colesoftware
> YouTube: www.youtube.com/user/colesoftware
>
>
>
>
>
>
> At 12/26/2016 04:44 PM, retired mainframer wrote:
>
>> As obnoxious has his postings are, more bandwidth is being wasted on
>> responses than his original rantings.  Once you recognize one of his names,
>> just create a kill filter and you won't see anything from him till he
>> changes the name.  If you feel you must do something, forward the message
>> to Darrel at ibm-main-requ...@listserv.ua.edu so he can be kicked off
>> the list.
>> -Original Message-
>>
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On Behalf Of Adam M. Dobrin
>>> Sent: Monday, December 26, 2016 11:53 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Censored by Global Media? proof of the existence of time
>>> travel found in religious scripture, links to prophesy of the return of
>>> Jesus Christ
>>> --
>>> 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 

Re: stop responding

[David Cole]

Absolutely! Just stop responding.

If you stop rising to his bait, he will no longer matter!
Just ignore him. if he doesn't go away, at least he will become irrelevant.

After all, how hard is it to add him to your SPAM filters?
For that matter, how hard is it to press DELETE?
Or to simply ignore his posts and move on with your lives?

Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware






At 12/26/2016 04:44 PM, retired mainframer wrote:
As obnoxious has his postings are, more bandwidth is being wasted on 
responses than his original rantings.  Once you recognize one of his 
names, just create a kill filter and you won't see anything from him 
till he changes the name.  If you feel you must do something, 
forward the message to Darrel at ibm-main-requ...@listserv.ua.edu so 
he can be kicked off the list.

-Original Message-
From: IBM Mainframe Discussion List 
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Adam M. Dobrin

Sent: Monday, December 26, 2016 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Censored by Global Media? proof of the existence of 
time travel found in religious scripture, links to prophesy of the 
return of Jesus Christ

--
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: A Christmassy PL/I tale

[Robert Prins]

Patrick,

On 2016-12-26 10:58, Patrick Vogt wrote:
> Hi Prino
>
>> Let's assume you gate-crash an IBM GSE meeting, way back in 2010 and talk
>> to an IBM developer about optimizing code, and he tells you that IBM is
>> well ahead (by "at least" five years) of the Open Source community!
>
> If you look at coding/automation on decentralized platforms, the Mainframe is
> technically still ahead of the other platforms. It may be slower on
> implementations but that's not to do with the Mainframe but of people coding
> like 20 years ago and structures of the companies.

That is so (expletive deleted) true. Take my last employer in Belgium, a 
semi-governmental health insurance. The show was run by an old fashioned 
Stalinist Secretary General, the CIO was parachuted in because he was a faithful 
member of the Socialist Party (and had been an advisor to a minister), but was a 
clueless idiot when it came to IT.


They (ab)used PL/I like there was no tomorrow. Running Enterprise PL/I V3.9 at 
the time (2009), 99% of their employees still used it as it it was OS PL/I 
V2.3.0, without realising that there were about a zillion new builtin functions, 
features like "UNION", much better diagnostic messages, you name it. Worst of 
all they were


1) compiling ARCH(2) on their ARCH(5) machine (and it took en email of IBM's 
Peter Elderon "Tell them they've got a car with six gears and only use two") to 
change that, and
2) an order, no several orders, worse, they were running with the LE STORAGE 
option set to "STORAGE(0,0,0,whatever)", "because the outfit that had helped 
them during the transition from OS PL/I to Enterprise PL/I had told them that 
this would take care on initializing variables." Yes, like PACKED DECIMAL with 
'0' sign nibbles...


They also didn't mind coding loops using zoned decimal fields, and I even found 
a recent program that was using GOTO to code loops, go figure...


>> .. Here is the output of the compiler, and lets start with the code
>> generated by the old OS compiler, and for what it's worth, w_hh and w_mm
>> are defined externally as "fixed dec (3)"
>
> for this tests, please post the complete/cropped Program. It's easier to copy
> and paste and then run the compiler.

I'll send you a copy, with the EPLI V4.3 options I use and the input file, or 
put those on my Google Drive, just in case others are also interested, PM me if 
you are.


> old:
>> ..01DA3A  D2 07 D 0B8 D 09B  MVC   S(8),WKSP.78+35
>>
>> L   :  3 ZAP : 18 MP  : 10 MVC : 23 DP  :  4 MVN :  8 NI  :  4 XC  :  4 XI
>> :  4 SP  :  4 --- 82 instructions, 470 bytes of code
>
> new:
>>
>> First thing that's noticable is that the code has become totally unreadable
>> to those with only a little knowledge of z/OS assembly language, everything
>> is #pdn and variable names are mostly gone and, hey, it looks like it's
>> a bit longer, so lets count:
>>
>> ZAP : 15 MP  : 10 MVC : 52 DP  :  4 MVN :  8 AHI :  1 XC  : 22 TM  :  2 SP
>> :  4 NC  :  4 SRP :  4 JE  :  2 --- 128 instructions, 758 bytes of code
>
> You alway's need good Assembler knowhow to understand at this level what the
> compiler does. It's easier to read if you disable all checks and
> optimizations.

The get a completely different load module. That's one of the other things I've 
always been dead against, testing a program with OPT(0) and then recompiling it 
into production, without retesting, using OPT(3).


> So for performance, please don't count the instructions but the bytes moved
> by the instructions and the place (Register, Storage, Cache) they are in. The
> Instructions are in the instruction cache and if you don't destroy the
> instruction cache, it's extremly fast.

Of course cached code is fast, and the cache on the z13 is huge, but when such a 
simple routine increases by around 50% in size, what happens with more complex 
routines. In the end cache will have to kick out code...


> As i have made some tests some time ago, here is my list (not complete) of
> fastest instruction types, fastest at top, example in brackets: -Immediate
> instructions (LHI) -Register to Register (LR) -Memory (read) to Register (L)
> -Memory(write) from Register (ST) -Memory to Memory (MVC)
>
> i don't know why, but at my tests, Immediate Instructions was faster than
> Register to Register... it may be wrong.. For Memory operations, it depend on
> the Datacache (Level x) it's in.
>
>> And the count, or rather the act of counting, immediately raises five very,
>> very significant questions:
>>
>> 1) What is the performance of the old code on a new z13 system compared to
>> the code that is now emitted?
>
> Don't know but needs to much time to test. :)

And as others have already said, time is the one resource we no longer have.

>> 2) There are still 10 MP instructions, and inspection of the code, which
>> was compiled ARCH(10) OPT(3) (in other words, as optimal as possible on the
>> hardware I have access to), reveals that Enterprise PL/I AD 2014 still
>> doesn't seem to 

Re: z/OS 2.2 SMF record corrupted

[Salva Carrasco]

After a long investigation, IBM has found an error when the SMF LogStream 
structure is defined with MAXBUFSIZE < 64K in z/OS 2.2.
Pending OA51823 APAR.

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