Re: Immediate instructions (was "nonames")

[Alan Altmark]

On Friday, 08/01/2008 at 09:17 EDT, Wayne Driscoll 
<[EMAIL PROTECTED]> wrote:
> Oh come on Alan, you learn the new machine (not assembler) instructions 
the
> IBM way, you look at what the PL/X (or whatever it is called today) 
compiler
> generates
> (gonna run and get my armor on before Chuckie replies)

Eh?  I don't know of any IBMer who learns opcodes by reading PL/X compiler 
output. I haven't looked at the output of a HLL compilation in years. What 
a horrible way to learn opcodes - it's far easier to read the POP. 
Further, at our chosen Architectural Level Set (z800/900) we don't allow 
the compilers to generate instructions that aren't on a z800/z900.

Alan Altmark
z/VM Development
IBM Endicott

Re: Immediate instructions (was "nonames")

[Jim Bohnsack]

DWIM?  I remember a couple of lives ago, in a galaxy far, far away, when 
I worked for IBM, the IBM conference/tools disk had a package called Do 
What I Mean.  That was back in 370 days.  I never pulled it down.  Too 
busy at that time trying to make HPO R4 and other abortions work. Same 
thing?  Maybe the developers were thinking ahead.  I wish they had been 
paying more attention to current things.


Jim

Schuh, Richard wrote:

Yes, but they still do not have DWIM.

Regards,=20
Richard Schuh=20

=20

  

--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]

Re: Immediate instructions (was "nonames")

[Wayne Driscoll]

Oh come on Alan, you learn the new machine (not assembler) instructions the
IBM way, you look at what the PL/X (or whatever it is called today) compiler
generates
(gonna run and get my armor on before Chuckie replies)

Wayne Driscoll
Product Developer
NOTE:  All opinions are strictly my own.




-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Friday, August 01, 2008 1:10 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Immediate instructions (was "nonames")

On Friday, 08/01/2008 at 01:48 EDT, "Ward, Mike S" <[EMAIL PROTECTED]> 
wrote:
> Where did you learn about the LHI instruction. I that a Load Halfword
> immediate? I looked at the hlasm books and they deal mostly with macros.
> I also looked at principle of operations manuals, but seem to have all
> the old assembler instructions and not any new ones.

Where did *I* learn?  I have, ummm, uhhh, let's just say: "connections". 
:-)

As you discovered, HLASM books describe the assembler, not the processor.

The current S/390 Principles of Operations is SA22-7201-08.
The current z/Architecture POP is SA22-7832-06.

If there's a new edition, there are new instructions.  The front chapters 
in those books (you know, the ones we all ignore?) can be very helpful. 
There may also be processor-specific publications/announcements that 
provide details - I don't know.

Alan Altmark
z/VM Development
IBM Endicott

Re: Immediate instructions (was "nonames")

[David Boyes]

> Yes, but they still do not have DWIM.

The Z doesn't, but my Xerox Dandelion does. 

Re: Immediate instructions (was "nonames")

[David Boyes]

> My fave is LOAD HALFWORD RELATIVE LONG.
> Say it a few times and it's practically a poem!

Chant it, and it'd make a decent mantra. 8-)

Re: Immediate instructions (was "nonames")

[Schuh, Richard]

Yes, but they still do not have DWIM.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On Behalf Of Jack Woehr
> Sent: Friday, August 01, 2008 3:56 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Immediate instructions (was "nonames")
> 
> Alan Altmark wrote:
> > On Friday, 08/01/2008 at 01:48 EDT, "Ward, Mike S" <[EMAIL PROTECTED]>
> > wrote:
> >   
> >> Where did you learn about the LHI instruction.
> Of course, TROO and TROT are pretty good, too.
> 
> -- 
> Jack J. Woehr# "Self-delusion is
> http://www.well.com/~jax #  half the battle!"
> http://www.softwoehr.com #  - Zippy the Pinhead
> 

Re: Immediate instructions (was "nonames")

[Jack Woehr]

Alan Altmark wrote:
On Friday, 08/01/2008 at 01:48 EDT, "Ward, Mike S" <[EMAIL PROTECTED]> 
wrote:
  

Where did you learn about the LHI instruction.

Of course, TROO and TROT are pretty good, too.

--
Jack J. Woehr# "Self-delusion is
http://www.well.com/~jax #  half the battle!"
http://www.softwoehr.com #  - Zippy the Pinhead

Re: Immediate instructions (was "nonames")

[Jack Woehr]

Alan Altmark wrote:
On Friday, 08/01/2008 at 01:48 EDT, "Ward, Mike S" <[EMAIL PROTECTED]> 
wrote:
  

Where did you learn about the LHI instruction.
Where did *I* learn?  I have, ummm, uhhh, let's just say: "connections". 
:-)
  

My fave is LOAD HALFWORD RELATIVE LONG.

Say it a few times and it's practically a poem!

--
Jack J. Woehr# "Self-delusion is
http://www.well.com/~jax #  half the battle!"
http://www.softwoehr.com #  - Zippy the Pinhead

Re: Immediate instructions (was "nonames")

[Jack Woehr]

Alan Altmark wrote:

The current S/390 Principles of Operations is SA22-7201-08.
  

http://publibz.boulder.ibm.com/epubs/pdf/dz9ar008.pdf

The current z/Architecture POP is SA22-7832-06.
  

http://publibz.boulder.ibm.com/epubs/pdf/dz9zr006.pdf

--
Jack J. Woehr# "Self-delusion is
http://www.well.com/~jax #  half the battle!"
http://www.softwoehr.com #  - Zippy the Pinhead

Re: Immediate instructions (was "nonames")

[Alan Altmark]

On Friday, 08/01/2008 at 01:48 EDT, "Ward, Mike S" <[EMAIL PROTECTED]> 
wrote:
> Where did you learn about the LHI instruction. I that a Load Halfword
> immediate? I looked at the hlasm books and they deal mostly with macros.
> I also looked at principle of operations manuals, but seem to have all
> the old assembler instructions and not any new ones.

Where did *I* learn?  I have, ummm, uhhh, let's just say: "connections". 
:-)

As you discovered, HLASM books describe the assembler, not the processor.

The current S/390 Principles of Operations is SA22-7201-08.
The current z/Architecture POP is SA22-7832-06.

If there's a new edition, there are new instructions.  The front chapters 
in those books (you know, the ones we all ignore?) can be very helpful. 
There may also be processor-specific publications/announcements that 
provide details - I don't know.

Alan Altmark
z/VM Development
IBM Endicott

Re: Missing the "nonames" option on SFS commands

[Schuh, Richard]

Look at the Load halfword. Both LH and LHI are described there in the
ESA POP.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ward, Mike S
> Sent: Friday, August 01, 2008 10:47 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Missing the "nonames" option on SFS commands
> 
> Where did you learn about the LHI instruction. I that a Load 
> Halfword immediate? I looked at the hlasm books and they deal 
> mostly with macros.
> I also looked at principle of operations manuals, but seem to 
> have all the old assembler instructions and not any new ones.
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark
> Sent: Friday, August 01, 2008 9:15 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Missing the "nonames" option on SFS commands
> 
> On Friday, 08/01/2008 at 09:44 EDT, Kris Buelens 
> <[EMAIL PROTECTED]>
> wrote:
> >   REGEQU
> >   USING *,R15
> >   L R15,=A(32)
> >   BRR14
> 
> Just to help folks advance their assembler programming, this 
> program would these days consist of
> REGEQU
> LHI  R15,32
> BR   R14
> 
> In S/390 architecture, Load Halfword Immediate sign-extends 
> the 16-bit second operand to 32 bits.  Note also the lack of 
> the USING.
> 
> I know it's off-topic, but it IS Friday!  :-)
> 
> Alan Altmark
> z/VM Development
> IBM Endicott
> ==
> This email and any files transmitted with it are confidential 
> and intended solely for the use of the individual or entity 
> to which they are addressed. If you have received this email 
> in error please notify the system manager. This message 
> contains confidential information and is intended only for 
> the individual named. If you are not the named addressee you 
> should not disseminate, distribute or copy this e-mail. 
> Please notify the sender immediately by e-mail if you have 
> received this e-mail by mistake and delete this e-mail from 
> your system. If you are not the intended recipient you are 
> notified that disclosing, copying, distributing or taking any 
> action in reliance on the contents of this information is 
> strictly prohibited.
> 
> 

Re: Missing the "nonames" option on SFS commands

[Ward, Mike S]

Where did you learn about the LHI instruction. I that a Load Halfword
immediate? I looked at the hlasm books and they deal mostly with macros.
I also looked at principle of operations manuals, but seem to have all
the old assembler instructions and not any new ones.

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Friday, August 01, 2008 9:15 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Missing the "nonames" option on SFS commands

On Friday, 08/01/2008 at 09:44 EDT, Kris Buelens
<[EMAIL PROTECTED]> 
wrote:
>   REGEQU
>   USING *,R15
>   L R15,=A(32)
>   BRR14

Just to help folks advance their assembler programming, this program
would 
these days consist of
REGEQU
LHI  R15,32
BR   R14

In S/390 architecture, Load Halfword Immediate sign-extends the 16-bit 
second operand to 32 bits.  Note also the lack of the USING.

I know it's off-topic, but it IS Friday!  :-)

Alan Altmark
z/VM Development
IBM Endicott
==
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity
to which they are addressed. If you have received this email in error please 
notify the system manager. This message
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from your system. 
If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this
information is strictly prohibited.

Re: SMAPI Java library?

[Jack Woehr]

Alan Altmark wrote:

The z/VM product does not include a Java class library for SMAPI.
  

Thanks, Alan, for your help. I guess we'll whip such a library together over
the next few weeks unless I do anything precipitous like get a job :-)

--
Jack J. Woehr# "Self-delusion is
http://www.well.com/~jax #  half the battle!"
http://www.softwoehr.com #  - Zippy the Pinhead

Re: Immediate instructions (was "nonames")

[Alan Altmark]

On Friday, 08/01/2008 at 12:29 EDT, Neale Ferguson <[EMAIL PROTECTED]> 
wrote:
> Don't forget you now have fullword immediate instructions. Gcc will
> automatically generate them and I've used them a lot in our OpenSolaris
> port.

The fullword instructions are available only in z/Architecture, not S/390 
(e.g. LFGI).  You need to IPL ZCMS to see it in action. 

Alan Altmark
z/VM Development
IBM Endicott

Re: SMAPI Java library?

[Alan Altmark]

On Friday, 08/01/2008 at 12:50 EDT, Jack Woehr <[EMAIL PROTECTED]> wrote:
> I'm just trying to ascertain that IBM is actually not providing an 
equivalent
> Java class library for z/VM
> SMAPI ... that appears to be the case ... if it is indeed the case we 
are 
> looking at writing such an open
> source class library.

The z/VM product does not include a Java class library for SMAPI.

Alan Altmark
z/VM Development
IBM Endicott

Re: Missing the "nonames" option on SFS commands

[Schuh, Richard]

You didn't mention the rule about using 0 (or R0) as a base register
value, either explicitly or by default in your list of rules for LA ;-)
That was the form I used. Only the increment value is loaded in that
case, so you are restricted to loading a value of 0-4095. 

When I was writing a lot of assembler programs there weren't as many
rules, i.e. no 64-bit considerations, and they were second nature to me.



Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark
> Sent: Friday, August 01, 2008 9:06 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Missing the "nonames" option on SFS commands
> 
> 
> Using LOAD ADDRESS requires that you learn all the little rules
> - The operand has to be 0-4095  (it's a displacement)
> - The maximum value of the register isn't what you think it is
> - That maximum value is different in AMODE 24 than it is in AMODE 31
> - There's no overflow protection with LA R1,10(,R1) since it 
> isn't an arithmetic operation
> - Don't forget the comma in (,R1)
> 
> If you could live with it, no problem, but it wasn't for the 
> uninitiated. 
> That's the nice thing about LHI, it was designed to load a 
> number into a register, not an address.
> 
> Now if you want to increment a register by 10:
>AHI R1,10
> 
> Just hoping folks learned something new today.  I'll be the 
> first to admit that these new (NOT!) instructions don't come 
> naturally to my fingertips.
> 
> Alan Altmark
> z/VM Development
> IBM Endicott
> 

Re: SMAPI Java library?

[Jack Woehr]

David Boyes wrote:
There are already Java libraries to front-end Sun RPC, so that would 
be one way to go about it. You'd have to feed the RPC stubs to rpcgen 
to get a proper mapping for your system, but that's not unusual 
behavior for Sun RPC app interfaces.

The new SMAPI in 5.3 is not RPC based, it's just socket programming.

See, on OS/400 (i/OS) there is the 
formerly-inhouse-IBM-project-now-Open-Source called JTOpen which
provides Java class objects to perform work on iSeries via host-resident 
TCP/IP service threads like the

SMAPI servers.

I'm just trying to ascertain that IBM is actually not providing an 
equivalent a Java class library for z/VM
SMAPI ... that appears to be the case ... if it is indeed the case we 
are looking at writing such an open

source class library.

Then on top of that we can write some Awesome GUI Stuph for z/VM.

--
Jack J. Woehr# "Self-delusion is
http://www.well.com/~jax #  half the battle!"
http://www.softwoehr.com #  - Zippy the Pinhead

Re: Nice idea in blog: Should we toss x86 architecture - NOT.

[Gary M. Dennis]

32 and 16 bit. The boot loaders used and FreeDos required incorporation of
16 bit support. Monumental pain.

We don't see 64 bit support being problematic though.

Gary


On 8/1/08 9:31 AM, "Adam Thornton" <[EMAIL PROTECTED]> wrote:

> Does z/VOS do x86_64 or just 32-bit x86?  Actually, can you list which
> x86 extensions are included in it?

Re: SMAPI Java library?

[David Boyes]

There are already Java libraries to front-end Sun RPC, so that would be one way 
to go about it. You'd have to feed the RPC stubs to rpcgen to get a proper 
mapping for your system, but that's not unusual behavior for Sun RPC app 
interfaces. 



From: The IBM z/VM Operating System on behalf of Jack Woehr
Sent: Thu 7/31/2008 5:05 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: SMAPI Java library?


Has IBM or anyone wrappered z/VM SMAPI 

  in Java classes akin to how the host servers
on i/OS got wrappered by JTOpen? I have not found anything, in particular, no 
open
source project.

 

Immediate instructions (was "nonames")

[Neale Ferguson]

Don't forget you now have fullword immediate instructions. Gcc will
automatically generate them and I've used them a lot in our OpenSolaris
port.


On 8/1/08 12:05 PM, "Alan Altmark" <[EMAIL PROTECTED]> wrote:
> Just hoping folks learned something new today.  I'll be the first to admit
> that these new (NOT!) instructions don't come naturally to my fingertips.

Re: Missing the "nonames" option on SFS commands

[Alan Altmark]

On Friday, 08/01/2008 at 11:43 EDT, "Schuh, Richard" <[EMAIL PROTECTED]> 
wrote:
> I would have thought that "LA R15,32" would have been a better
> instruction to use than "L R15, =A(32)". I know that in olden days it
> burned less carbon. I don't know what the comparison with the LHI would
> be, but imagine that the two would be pretty close since both actually
> load the operands when the instruction is fetched, with no memory access
> needed.

Using LOAD ADDRESS requires that you learn all the little rules
- The operand has to be 0-4095  (it's a displacement)
- The maximum value of the register isn't what you think it is
- That maximum value is different in AMODE 24 than it is in AMODE 31
- There's no overflow protection with LA R1,10(,R1) since it isn't an 
arithmetic operation
- Don't forget the comma in (,R1)

If you could live with it, no problem, but it wasn't for the uninitiated. 
That's the nice thing about LHI, it was designed to load a number into a 
register, not an address.

Now if you want to increment a register by 10:
   AHI R1,10

Just hoping folks learned something new today.  I'll be the first to admit 
that these new (NOT!) instructions don't come naturally to my fingertips.

Alan Altmark
z/VM Development
IBM Endicott

Re: Missing the "nonames" option on SFS commands

[Schuh, Richard]

I would have thought that "LA R15,32" would have been a better
instruction to use than "L R15, =A(32)". I know that in olden days it
burned less carbon. I don't know what the comparison with the LHI would
be, but imagine that the two would be pretty close since both actually
load the operands when the instruction is fetched, with no memory access
needed. 

I was asked once to write a small program on OS/MFT that would burn
cycles. I named it IEFBR15. It was even shorter and did the job. For
such a trivial program, I didn't bother with the REGEQU.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark
> Sent: Friday, August 01, 2008 7:15 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Missing the "nonames" option on SFS commands
> 
> On Friday, 08/01/2008 at 09:44 EDT, Kris Buelens 
> <[EMAIL PROTECTED]>
> wrote:
> >   REGEQU
> >   USING *,R15
> >   L R15,=A(32)
> >   BRR14
> 
> Just to help folks advance their assembler programming, this 
> program would these days consist of
> REGEQU
> LHI  R15,32
> BR   R14
> 
> In S/390 architecture, Load Halfword Immediate sign-extends 
> the 16-bit second operand to 32 bits.  Note also the lack of 
> the USING.
> 
> I know it's off-topic, but it IS Friday!  :-)
> 
> Alan Altmark
> z/VM Development
> IBM Endicott
> 

Re: DOS attack details in

[Tony Noto]

We have seen these from time to time. When we get them, they come in one
of two flavors. Either someone pounding SNMP to try to use us as an open
relay or more frequently in an attempt to DOS or hack us via FTP.

To help minimize (not eliminate) the impact, we have EXITs in place for
both SMTP and FTP. For SNMP, an forwarding causes the EXIT to issue a
NETSTAT BLOCK for the IP address.

In the case of FTP, our EXIT checks for an attempt to use an ID of
ADMINxxx (and a collection of others). When that occurs, again ... NETSTAT
BLOCK offending IP address.

And of course when the DOS is purely DOS, and the only signal is a
notification from TCPIP, we manually do a NETSTAT BLOCK for xxx.xxx.*

Of course, the last example catches an entire network, but only once have
we inadvertently stop a legitimate site from being to reach us.

The result doesn't alway truly stop the offender, but it minimizes the
impact on TCPIP and of course, our security console activity.

> On Thu, 31 Jul 2008 08:27:43 -0500, Mike Walter <[EMAIL PROTECTED]>
> wrote:
>
>>Back on July 15, we experienced our first known Denial of Service
>> "attack"
>>(more likely a problem server).
>>I reported it to our Internet Security group including:
>>
>>From the nearly anonymous/invisible "TCPIPMESSAGE" file in
>>TCPMAINT's reader:
>>---
>>DTCUTI001E Serious problem encountered: 15:38:55 07/15/08
>>DTCUTI002E A denial-of-service attack has been detected
>>--
>
> Nearly invisible? They show up in my reader and have since I moved into VM
> Systems. Far from
> being anonymous/invisible, they are rather overly frequent.
>
> Since I have 20 (?) of those readers, I long ago arranged to forward SOME
> of these messages to my
> email address. The rest just go in a log file.
>
> Like you, we found the DOS came from our Information Security folk's
> server. (At least they didn't
> try to hide it -- there is an email address attached.) So far we haven't
> ever gotten a nastygram
> from these folks telling us we are insecure, but I have seen such emails
> addressed to others.
> Presumably that means VM does the right thing. Like others our VM systems
> are behind a firewall.
> But information security warns us that insiders are more of a threat than
> outsiders.
>
> Alan Ackerman
> Alan (dot) Ackerman (at) Bank of America (dot) com
>


Regards,

Tony Noto
Software Development Manager
Velocity Software, Inc
650/964-8867
http://www.velocitysoftware.com

Re: Loosing IP after IPL: CTC free

[Kris Buelens]

My former customer's AUTOLOG1 performed a few checks before it even started
RACFVM. That function would get lost if CP would xautolog the ESM directly:
for example there was a time we needed an extra to VARY ON of some DASD
before we would go on.  It also verified that the LPAR name matched the VM
ID.  I don't have a list to see if everything is now obsolete or could be
moved to AUTOLGO2 after all.

2008/8/1 Adam Thornton <[EMAIL PROTECTED]>

> On Aug 1, 2008, at 10:09 AM, Rob van der Heij wrote:
>
>  On Fri, Aug 1, 2008 at 4:40 PM, Alan Altmark <[EMAIL PROTECTED]>
>> wrote:
>>
>>  And while I'm halucinating, I would have a command that adds and deletes
>>> users from an autolog list.  The list is in the warm start area.  No
>>> requirement for AUTOLOG1 unless you want it.  Oh, and the autologs would
>>> be paced to ensure that the system is not brought to its knees during
>>> IPL.
>>>
>>
>> We did run PROP in AUTOLOG2 and it would also get the message when the
>> autologged user went away, it allowed the operator to check the
>> status, etc. It allowed people to add things to the list (also users
>> could request their own server to be started). IIRC we had a disk with
>> a file per userid to be autologged, and the file itself had
>> information about when it should be started and on what system and who
>> to alert when it broke.
>>
>> I think David recently also did something like this.
>>
>
> If by "David," you mean "Adam," then yes, the answer is we did, it was
> SYSVINIT.  It's at http://download.sinenomine.net/sysvinit/
>
> It wasn't quite as sophisticated as all that, but it's a lot more
> sophisticated than a list of XAUTOLOGS interspersed with CP SLEEPS.
>
> The URL in the WAAV presentation there is no longer valid.  But if you got
> to the WAAV presentation, you're there.
>
> The community response to SYSVINIT was deafening silence, which sort of
> surprised me, as it really DID provide a nice flexible mechanism for
> automating startup with real dependency checking.  Although the log disk
> fills up--I never got around to adding an autocleaner to it--and I never got
> midnight message trapping to work correctly.
>
> Still, if there's actually SOME interest in it, I might be eventually
> persuaded to address that.  If not, hey, it's all Rexx, so feel free.
>
> Adam
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: Missing the "nonames" option on SFS commands

[Schuh, Richard]

That would be fine as a circumvention if you were the only one affected
and were in a hurry, but it does not fix the problem. 

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens
> Sent: Friday, August 01, 2008 6:45 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Missing the "nonames" option on SFS commands
> 
> For some commands, there are CSL routines, and most of those 
> don't do nickname resolution, for others you are right.
> I discussed this with Alan quite some years ago.  He 
> suggested to NUCXLOAD a module as NAMEFIND
> 

Re: Loosing IP after IPL: CTC free

[Adam Thornton]

On Aug 1, 2008, at 10:09 AM, Rob van der Heij wrote:

On Fri, Aug 1, 2008 at 4:40 PM, Alan Altmark  
<[EMAIL PROTECTED]> wrote:


And while I'm halucinating, I would have a command that adds and  
deletes

users from an autolog list.  The list is in the warm start area.  No
requirement for AUTOLOG1 unless you want it.  Oh, and the autologs  
would
be paced to ensure that the system is not brought to its knees  
during IPL.


We did run PROP in AUTOLOG2 and it would also get the message when the
autologged user went away, it allowed the operator to check the
status, etc. It allowed people to add things to the list (also users
could request their own server to be started). IIRC we had a disk with
a file per userid to be autologged, and the file itself had
information about when it should be started and on what system and who
to alert when it broke.

I think David recently also did something like this.


If by "David," you mean "Adam," then yes, the answer is we did, it was  
SYSVINIT.  It's at http://download.sinenomine.net/sysvinit/


It wasn't quite as sophisticated as all that, but it's a lot more  
sophisticated than a list of XAUTOLOGS interspersed with CP SLEEPS.


The URL in the WAAV presentation there is no longer valid.  But if you  
got to the WAAV presentation, you're there.


The community response to SYSVINIT was deafening silence, which sort  
of surprised me, as it really DID provide a nice flexible mechanism  
for automating startup with real dependency checking.  Although the  
log disk fills up--I never got around to adding an autocleaner to it-- 
and I never got midnight message trapping to work correctly.


Still, if there's actually SOME interest in it, I might be eventually  
persuaded to address that.  If not, hey, it's all Rexx, so feel free.


Adam

Re: DOS attack details in

[Schuh, Richard]

That only makes sense. After all, who has the easiest access and the
most knowledge of the systems?


Regards, 
Richard Schuh 

 

> But information security warns us that insiders are more of a 
> threat than=  outsiders.
> 
> Alan Ackerman
> Alan (dot) Ackerman (at) Bank of America (dot) com 
> 

Re: Loosing IP after IPL: CTC free

[Rob van der Heij]

On Fri, Aug 1, 2008 at 4:40 PM, Alan Altmark <[EMAIL PROTECTED]> wrote:

> And while I'm halucinating, I would have a command that adds and deletes
> users from an autolog list.  The list is in the warm start area.  No
> requirement for AUTOLOG1 unless you want it.  Oh, and the autologs would
> be paced to ensure that the system is not brought to its knees during IPL.

We did run PROP in AUTOLOG2 and it would also get the message when the
autologged user went away, it allowed the operator to check the
status, etc. It allowed people to add things to the list (also users
could request their own server to be started). IIRC we had a disk with
a file per userid to be autologged, and the file itself had
information about when it should be started and on what system and who
to alert when it broke.

I think David recently also did something like this.

-Rob

Re: Loosing IP after IPL: CTC free

[Alan Altmark]

On Friday, 08/01/2008 at 10:01 EDT, Rob van der Heij <[EMAIL PROTECTED]> 
wrote:

> I am thinking it would be a neat idea to put the XAUTOLOG as CP
> commands in the directory entry.
> 
> :soapbox.
> It may be too late, but &deity should done RACF startup the other way
> around: change CP to start a new AUTOLOGx at IPL that will bring up
> RACFVM, and have RACFVM start AUTOLOG1 as the customer had it
> before...
> :esoapbox.

Been there.  Thought that.  The correct way to do this is to identify ALL 
of the required ESM servers in SYSTEM CONFIG.  When all ESMs have 
signalled "Ready" to CP, then CP starts AUTOLOG1.  In the event of a 
timeout, CP issues a message skips starting AUTOLOG1.

And while I'm halucinating, I would have a command that adds and deletes 
users from an autolog list.  The list is in the warm start area.  No 
requirement for AUTOLOG1 unless you want it.  Oh, and the autologs would 
be paced to ensure that the system is not brought to its knees during IPL.

And I want a pony.

Alan Altmark
z/VM Development
IBM Endicott

Re: Nice idea in blog: Should we toss x86 architecture - NOT.

[Adam Thornton]

On Jul 31, 2008, at 5:08 PM, Gary M. Dennis wrote:

z/VOS translates guest OS code during initial execution. Code fragment
storage, lookup, disposal and reuse for primary and sibling guests are
addressed in a patent application.  Suffice it to say that we don't
interpret or emulate massive amounts of x86 code for use 2-n.


Ah, the old ARDI Executor approach.

Well, probably not *exactly* if there's enough novel in there to  
patent, but, yeah, JIT instruction-stream-translation with caching of  
commonly-reused fragments was the way ARDI was emulating 68K Macs on  
Pentiums back in, oh, 1996 or so.  That would (of course) be a better  
way to cut your overhead, because if you have a long sequence of s390x  
instructions mapped (nearly 1-to-1) to a long sequence of x86(_64?)  
instructions, then you only take the "wrapping the registers and  
shifting the arguments around" hit once per chunk, and a lot of x86  
executable code is a) boilerplate and b) common in most executables  
produced by the same compiler, so this could actually be a very big win.


Does z/VOS do x86_64 or just 32-bit x86?  Actually, can you list which  
x86 extensions are included in it?   Or do I need to wait for release  
to find out.


Adam

Re: Missing the "nonames" option on SFS commands

[Rob van der Heij]

On Fri, Aug 1, 2008 at 4:14 PM, Alan Altmark <[EMAIL PROTECTED]> wrote:

> In S/390 architecture, Load Halfword Immediate sign-extends the 16-bit
> second operand to 32 bits.  Note also the lack of the USING.

And the lack of an END statement... ;-)

So if the suggestion is to mess with the NAMEFIND, then I think I
would rather make the assembler program a bit larger and have it
process the argument string as a CMS command.
  'NONAMES GRANT AUTH' path 'TO' user '( READ NEWREAD'
without risking to pick up a nickname.

Considering that SFS has options at the wrong place of the command
anyway, this is probably pretty good.

Rob

Re: Dirmaint unknown user id

[Doug Breneman]

Yes, Thank you.
Doug Breneman  z/VM Development  IBM Endicott, NY


|>
| From:  |
|>
  
>-|
  |Howard Rifkind <[EMAIL PROTECTED]>   
|
  
>-|
|>
| To:|
|>
  
>-|
  |IBMVM@LISTSERV.UARK.EDU  
|
  
>-|
|>
| Date:  |
|>
  
>-|
  |08/01/2008 10:04 AM  
|
  
>-|
|>
| Subject:   |
|>
  
>-|
  |Re: Dirmaint unknown user id 
|
  
>-|





Thanks Doug...

Wouldn't the current PMR be O.K.

>>> Doug Breneman <[EMAIL PROTECTED]> 8/1/2008 9:59 AM >>>


Hi Howard,
While I encourage you to open a PMR, I wanted to let you know that I
forwarded this information to the lead DirMaint developer.
Doug Breneman z/VM Development IBM Endicott, NY

Inactive hide details for Howard Rifkind ---08/01/2008 09:32:55
AM---Thanks, this is exactly what I did. >>> Kris Buelens >>
Kris Buelens <[EMAIL PROTECTED]> 8/1/2008 4:18 AM >>>
   
   
 From: Howard Rifkind <[EMAIL PROTECTED]>  
   
   
 To:   IBMVM@LISTSERV.UARK.EDU 
   
   
 Date: 08/01/2008 09:32 AM 
   
   
 Subject:  Re: Dirmaint unknown user id
   





Thanks, this is exactly what I did.

>>> Kris Buelens <[EMAIL PROTECTED]> 8/1/2008 4:18 AM >>>
I think I have seen something like this too in Dirmaint 5.3, I suppose
Dirmaint (better DATAMOVE) will finally help you when it can't
complete a DMDISK/CMDISK due to existing links.
To me this looks like a not unitialized REXX variable. Maybe the code
contains a PIPE like
PIPE CP Q LINKS | ... | VAR LinkHolders'
and doesn't test: if Symbol('LinkHolders')<>'VAR' 

To be short: open a PMR

2008/7/31 Howard Rifkind <[EMAIL PROTECTED]>:
> Has anyone seen something like this from Dirmaint.
>
> I'm interested where the user LILNKHOLDERS is coming from.
>
> Thanks
>
> DVHDMC6831E active links held by the following users: LINKHOLDERS
>
>
>
>
> _
> LEGAL NOTICE
> Unless expressly stated otherwise, this message is confidential
> and may be privileged. It is intended for the addressee(s) only.
> Access to this E-mail by anyone else is unauthorized.
> If you are not an addressee, any disclosure or copying of the
> contents of this E-mail or any action taken (or not taken) in
> reliance on it is unauthorized and may be unlawful. If you are not an
> addressee, please inform the sender immediately, then delete this
> message and empty from your trash.
>



--
Kris Buelens,
IBM Belgium, VM customer support



 _
 LEGAL NOTICE
 Unless expressly stated otherwise, this message is
 confidential
 and may be privileged. It is intended for the
 addressee(s) only.
 Access to this E-mail by anyone

Re: Loosing IP after IPL: CTC free

[Rob van der Heij]

On Fri, Aug 1, 2008 at 4:08 PM, Thomas Kern <[EMAIL PROTECTED]> wrote:

> I think that is still one layer of activity too much. The ESM should be as
> much a part of a WARM start as DISKACNT, EREP and OPERATNS. There should be
> an extendable list of MANDATORY svms in the system config file and they
> should all be autologed during a WARM start. A FORCE, COLD, CLEAN start
> imply other problems and the startup of these servers might not be prudent,
> so make every thing manual during those startups.

Well... maybe...   but part of the challenge is that you could also
run RACMAINT as your ESM when RACFVM is sick. And some shops need to
run multiple ESMs. Ideally, you could put such logic now in the
autolog machine where you have more facilities than in the system
configuration file.
We used to have AUTOLOG2 wait for the operator to kick of the rest so
we could implement changes just after IPL.
-Rob

Re: Missing the "nonames" option on SFS commands

[Alan Altmark]

On Friday, 08/01/2008 at 09:44 EDT, Kris Buelens <[EMAIL PROTECTED]> 
wrote:
>   REGEQU
>   USING *,R15
>   L R15,=A(32)
>   BRR14

Just to help folks advance their assembler programming, this program would 
these days consist of
REGEQU
LHI  R15,32
BR   R14

In S/390 architecture, Load Halfword Immediate sign-extends the 16-bit 
second operand to 32 bits.  Note also the lack of the USING.

I know it's off-topic, but it IS Friday!  :-)

Alan Altmark
z/VM Development
IBM Endicott

Re: Loosing IP after IPL: CTC free

[Thomas Kern]

I think that is still one layer of activity too much. The ESM should be a
s
much a part of a WARM start as DISKACNT, EREP and OPERATNS. There should 
be
an extendable list of MANDATORY svms in the system config file and they
should all be autologed during a WARM start. A FORCE, COLD, CLEAN start
imply other problems and the startup of these servers might not be pruden
t,
so make every thing manual during those startups.

/Tom Kern
/301-903-2211

On Fri, 1 Aug 2008 16:00:35 +0200, Rob van der Heij <[EMAIL PROTECTED]> w
rote:
>I am thinking it would be a neat idea to put the XAUTOLOG as CP
>commands in the directory entry.
>
>:soapbox.
>It may be too late, but &deity should done RACF startup the other wa
y
>around: change CP to start a new AUTOLOGx at IPL that will bring up
>RACFVM, and have RACFVM start AUTOLOG1 as the customer had it
>before...
>:esoapbox.
>
>Rob
>
=

Re: Dirmaint unknown user id

[Howard Rifkind]

Thanks Doug...
 
Wouldn't the current PMR be O.K.

>>> Doug Breneman <[EMAIL PROTECTED]> 8/1/2008 9:59 AM >>>

Hi Howard,
While I encourage you to open a PMR, I wanted to let you know that I forwarded 
this information to the lead DirMaint developer.
Doug Breneman z/VM Development IBM Endicott, NY

Kris Buelens Howard Rifkind ---08/01/2008 09:32:55 AM---Thanks, this is exactly 
what I did. >>> Kris Buelens <[EMAIL PROTECTED]> 8/1/2008 4:18 AM >>>



From:
Howard Rifkind <[EMAIL PROTECTED]>

To:
IBMVM@LISTSERV.UARK.EDU 

Date:
08/01/2008 09:32 AM

Subject:
Re: Dirmaint unknown user id



Thanks, this is exactly what I did.

>>> Kris Buelens <[EMAIL PROTECTED]> 8/1/2008 4:18 AM >>>
I think I have seen something like this too in Dirmaint 5.3, I suppose
Dirmaint (better DATAMOVE) will finally help you when it can't
complete a DMDISK/CMDISK due to existing links.
To me this looks like a not unitialized REXX variable. Maybe the code
contains a PIPE like
PIPE CP Q LINKS | ... | VAR LinkHolders'
and doesn't test: if Symbol('LinkHolders')<>'VAR' 

To be short: open a PMR

2008/7/31 Howard Rifkind <[EMAIL PROTECTED]>:
> Has anyone seen something like this from Dirmaint.
>
> I'm interested where the user LILNKHOLDERS is coming from.
>
> Thanks
>
> DVHDMC6831E active links held by the following users: LINKHOLDERS
>
>
>
>
> _
> LEGAL NOTICE
> Unless expressly stated otherwise, this message is confidential
> and may be privileged. It is intended for the addressee(s) only.
> Access to this E-mail by anyone else is unauthorized.
> If you are not an addressee, any disclosure or copying of the
> contents of this E-mail or any action taken (or not taken) in
> reliance on it is unauthorized and may be unlawful. If you are not an
> addressee, please inform the sender immediately, then delete this
> message and empty from your trash.
>



-- 
Kris Buelens,
IBM Belgium, VM customer support




_
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the
contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately, then delete this
message and empty from your trash.


_
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the
contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately, then delete this
message and empty from your trash.

Re: Loosing IP after IPL: CTC free

[Ian S. Worthington]

That fixed it, many thanks!
i

-- Original Message --
Received: Fri, 01 Aug 2008 02:48:21 PM BST
From: Kris Buelens <[EMAIL PROTECTED]>
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Loosing IP after IPL: CTC free

> It is in the PEROFILE EXEC of AUTOLOG1 that you must insert an
> XAUTOLOG TCPIP.  AUTOLOG1 is started after a CP IPL, it's only task is
> to start other users.  If you'd have RACFVM, AUTOLOG1 only starts
> RACFVM; RACFVM then starts AUTOLOG2, that would then start everything
> else.
> 
> (the XAUTOLOG statements in the CP directory define which class G
> users are authorized to XAUTOLOG the given userid).
> 
> 2008/8/1 Ian S. Worthington <[EMAIL PROTECTED]>:
> > Hi Rob --
> >
> > My apologies: I'm much more of an MVS person - I'm only pretending to do
VM as
> > a favour, so your questions are a bit over my head I'm afraid.
> >
> > XAUTOLOG would be defined in the USER DIRECT (this is the PWD 5.3
system),
> > yes?  TCPIP is defined as below - no xautolog:
> >
> > USER TCPIP TCPIP 32M 128M ABG
> >  INCLUDE TCPCMSU
> >  OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON
> >  SHARE RELATIVE 3000
> >  IUCV ALLOW
> >  IUCV ANY PRIORITY
> >  IUCV *CCS PRIORITY MSGLIMIT 255
> >  IUCV *VSWITCH MSGLIMIT 65535
> >  LINK 5VMTCP30 491 491 RR
> >  LINK 5VMTCP30 492 492 RR
> >  LINK TCPMAINT 591 591 RR
> >  LINK TCPMAINT 592 592 RR
> >  LINK TCPMAINT 198 198 RR
> >  MDISK 191 3390 3057 005 530W01  MR RTCPIP   WTCPIP   MTCPIP
> >
> > PROFILE TCPCMSU
> >  IPL CMS
> >  MACH XA
> >  SPOOL 000C 2540 READER *
> >  SPOOL 000D 2540 PUNCH A
> >  SPOOL 000E 1403 A
> >  CONSOLE 009 3215 T
> >  LINK MAINT 0190 0190 RR
> >  LINK MAINT 019D 019D RR
> >  LINK MAINT 019E 019E RR
> >  LINK MAINT 0402 0402 RR
> >  LINK MAINT 0401 0401 RR
> >  LINK MAINT 0405 0405 RR
> >
> >
> > On TCPMAINT 198 there's:
> >
> >  SYSTEM   DTCPARMS D1 V 71  1BLK 08/08/01
> >  ===>
> > .*
> > .* SYSTEM DTCPARMS created by DTCIPWIZ EXEC on 1 Aug 2008
> > .* Configuration program run by MAINT at 09:04:12
> > .*
> > :nick.TCPIP:type.server
> >   :class.stack
> >   :attach.0E40-0E41
> >  * * * End of File * * *
> >
> > As IP does come up after the IPWIZARD I would guess the device definitions
are
> > ok?  Currently I see:
> >
> > q ctc
> > CTCA 0E40 ATTACHED TO TCPIP0E40
> > CTCA 0E41 ATTACHED TO TCPIP0E41
> >
> >
> > Is it just a case of adding an XAUTOLOG to the TCPIP defintion?
> >
> > Apologies for my ignorance.
> >
> > ian
> > ...
> >
> >
> >
> > -- Original Message --
> > Received: Fri, 01 Aug 2008 02:22:19 PM BST
> > From: Rob van der Heij <[EMAIL PROTECTED]>
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Re: Loosing IP after IPL: CTC free
> >
> >> On Fri, Aug 1, 2008 at 3:14 PM, Ian S. Worthington
> >> <[EMAIL PROTECTED]> wrote:
> >> > I've successfully run IPWIZARD and can connect to my system until I
ipl.
> >> >
> >> > After that I notice that the CTC is FREE, whereas after IPWIZARD its
> > "ATTACHED
> >> > TO TCPIP".
> >> >
> >> > I'm guessing this is the cause of the problem. What do I have to do to
> > make
> >> > this sticky please?
> >>
> >> Do you XAUTOLOG TCPIP during startup? You should have 2 devices
> >> attached. Did the DTCPARMS file get built by IPWIZARD ? Can the
> >> devices be attached to TCPIP? (it does by default an ATTACH where
> >> real=virt and that breaks when your real device happens to be where
> >> the sample stack has another device).
> >>
> >> Rob
> >>
> 
> 
> 
> -- 
> Kris Buelens,
> IBM Belgium, VM customer support
> 

Re: Loosing IP after IPL: CTC free

[Rob van der Heij]

On Fri, Aug 1, 2008 at 3:48 PM, Kris Buelens <[EMAIL PROTECTED]> wrote:

> It is in the PEROFILE EXEC of AUTOLOG1 that you must insert an
> XAUTOLOG TCPIP.  AUTOLOG1 is started after a CP IPL, it's only task is
> to start other users.  If you'd have RACFVM, AUTOLOG1 only starts
> RACFVM; RACFVM then starts AUTOLOG2, that would then start everything
> else.

I am thinking it would be a neat idea to put the XAUTOLOG as CP
commands in the directory entry.

:soapbox.
It may be too late, but &deity should done RACF startup the other way
around: change CP to start a new AUTOLOGx at IPL that will bring up
RACFVM, and have RACFVM start AUTOLOG1 as the customer had it
before...
:esoapbox.

Rob

Re: Dirmaint unknown user id

[Doug Breneman]

Hi Howard,
While I encourage you to open a PMR, I wanted to let you know that I
forwarded this information to the lead DirMaint developer.
Doug Breneman  z/VM Development IBM  Endicott, NY


|>
| From:  |
|>
  
>-|
  |Howard Rifkind <[EMAIL PROTECTED]>   
|
  
>-|
|>
| To:|
|>
  
>-|
  |IBMVM@LISTSERV.UARK.EDU  
|
  
>-|
|>
| Date:  |
|>
  
>-|
  |08/01/2008 09:32 AM  
|
  
>-|
|>
| Subject:   |
|>
  
>-|
  |Re: Dirmaint unknown user id 
|
  
>-|





Thanks, this is exactly what I did.

>>> Kris Buelens <[EMAIL PROTECTED]> 8/1/2008 4:18 AM >>>
I think I have seen something like this too in Dirmaint 5.3, I suppose
Dirmaint (better DATAMOVE) will finally help you when it can't
complete a DMDISK/CMDISK due to existing links.
To me this looks like a not unitialized REXX variable.  Maybe the code
contains a PIPE like
   PIPE CP Q LINKS | ... | VAR LinkHolders'
and doesn't test: if Symbol('LinkHolders')<>'VAR' 

To be short: open a PMR

2008/7/31 Howard Rifkind <[EMAIL PROTECTED]>:
> Has anyone seen something like this from Dirmaint.
>
> I'm interested where the user LILNKHOLDERS is coming from.
>
> Thanks
>
> DVHDMC6831E active links held by the following users: LINKHOLDERS
>
>
>
>
> _
> LEGAL NOTICE
> Unless expressly stated otherwise, this message is confidential
> and may be privileged. It is intended for the addressee(s) only.
> Access to this E-mail by anyone else is unauthorized.
> If you are not an addressee, any disclosure or copying of the
> contents of this E-mail or any action taken (or not taken) in
> reliance on it is unauthorized and may be unlawful. If you are not an
> addressee, please inform the sender immediately, then delete this
> message and empty from your trash.
>



--
Kris Buelens,
IBM Belgium, VM customer support




 _
 LEGAL NOTICE
 Unless expressly stated otherwise, this message is
 confidential
 and may be privileged. It is intended for the
 addressee(s) only.
 Access to this E-mail by anyone else is
 unauthorized.
 If you are not an addressee, any disclosure or
 copying of the
 contents of this E-mail or any action taken (or
 not taken) in
 reliance on it is unauthorized and may be
 unlawful. If you are not an
 addressee, please inform the sender immediately,
 then delete this
 message and empty from your trash.

Re: Loosing IP after IPL: CTC free

[Wayne Driscoll]

Ian,
What type of an IPL are you performing?  If you issue 
IND USER TCPIP
What results do you get?

Wayne Driscoll
Product Developer
NOTE:  All opinions are strictly my own.




-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Ian S. Worthington
Sent: Friday, August 01, 2008 8:14 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Loosing IP after IPL: CTC free

I've successfully run IPWIZARD and can connect to my system until I ipl.

After that I notice that the CTC is FREE, whereas after IPWIZARD its
"ATTACHED
TO TCPIP".

I'm guessing this is the cause of the problem. What do I have to do to make
this sticky please?


ian 
... 

Ian S. Worthington, MBCS.

me: http://isw.me.uk/ 
photos: http://gallery.isw.me.uk/ 


Dulce et decorum est pro patria mori, sed dulcius pro patria vivere, et
dulcissimus pro patria biber. Ergo, bibiamo pro salute patriae.

Re: Loosing IP after IPL: CTC free

[Kris Buelens]

It is in the PEROFILE EXEC of AUTOLOG1 that you must insert an
XAUTOLOG TCPIP.  AUTOLOG1 is started after a CP IPL, it's only task is
to start other users.  If you'd have RACFVM, AUTOLOG1 only starts
RACFVM; RACFVM then starts AUTOLOG2, that would then start everything
else.

(the XAUTOLOG statements in the CP directory define which class G
users are authorized to XAUTOLOG the given userid).

2008/8/1 Ian S. Worthington <[EMAIL PROTECTED]>:
> Hi Rob --
>
> My apologies: I'm much more of an MVS person - I'm only pretending to do VM as
> a favour, so your questions are a bit over my head I'm afraid.
>
> XAUTOLOG would be defined in the USER DIRECT (this is the PWD 5.3 system),
> yes?  TCPIP is defined as below - no xautolog:
>
> USER TCPIP TCPIP 32M 128M ABG
>  INCLUDE TCPCMSU
>  OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON
>  SHARE RELATIVE 3000
>  IUCV ALLOW
>  IUCV ANY PRIORITY
>  IUCV *CCS PRIORITY MSGLIMIT 255
>  IUCV *VSWITCH MSGLIMIT 65535
>  LINK 5VMTCP30 491 491 RR
>  LINK 5VMTCP30 492 492 RR
>  LINK TCPMAINT 591 591 RR
>  LINK TCPMAINT 592 592 RR
>  LINK TCPMAINT 198 198 RR
>  MDISK 191 3390 3057 005 530W01  MR RTCPIP   WTCPIP   MTCPIP
>
> PROFILE TCPCMSU
>  IPL CMS
>  MACH XA
>  SPOOL 000C 2540 READER *
>  SPOOL 000D 2540 PUNCH A
>  SPOOL 000E 1403 A
>  CONSOLE 009 3215 T
>  LINK MAINT 0190 0190 RR
>  LINK MAINT 019D 019D RR
>  LINK MAINT 019E 019E RR
>  LINK MAINT 0402 0402 RR
>  LINK MAINT 0401 0401 RR
>  LINK MAINT 0405 0405 RR
>
>
> On TCPMAINT 198 there's:
>
>  SYSTEM   DTCPARMS D1 V 71  1BLK 08/08/01
>  ===>
> .*
> .* SYSTEM DTCPARMS created by DTCIPWIZ EXEC on 1 Aug 2008
> .* Configuration program run by MAINT at 09:04:12
> .*
> :nick.TCPIP:type.server
>   :class.stack
>   :attach.0E40-0E41
>  * * * End of File * * *
>
> As IP does come up after the IPWIZARD I would guess the device definitions are
> ok?  Currently I see:
>
> q ctc
> CTCA 0E40 ATTACHED TO TCPIP0E40
> CTCA 0E41 ATTACHED TO TCPIP0E41
>
>
> Is it just a case of adding an XAUTOLOG to the TCPIP defintion?
>
> Apologies for my ignorance.
>
> ian
> ...
>
>
>
> -- Original Message --
> Received: Fri, 01 Aug 2008 02:22:19 PM BST
> From: Rob van der Heij <[EMAIL PROTECTED]>
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Loosing IP after IPL: CTC free
>
>> On Fri, Aug 1, 2008 at 3:14 PM, Ian S. Worthington
>> <[EMAIL PROTECTED]> wrote:
>> > I've successfully run IPWIZARD and can connect to my system until I ipl.
>> >
>> > After that I notice that the CTC is FREE, whereas after IPWIZARD its
> "ATTACHED
>> > TO TCPIP".
>> >
>> > I'm guessing this is the cause of the problem. What do I have to do to
> make
>> > this sticky please?
>>
>> Do you XAUTOLOG TCPIP during startup? You should have 2 devices
>> attached. Did the DTCPARMS file get built by IPWIZARD ? Can the
>> devices be attached to TCPIP? (it does by default an ATTACH where
>> real=virt and that breaks when your real device happens to be where
>> the sample stack has another device).
>>
>> Rob
>>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: Missing the "nonames" option on SFS commands

[Kris Buelens]

For some commands, there are CSL routines, and most of those don't do
nickname resolution, for others you are right.
I discussed this with Alan quite some years ago.  He suggested to
NUCXLOAD a module as NAMEFIND

Here's my -NONICK ASSEMBLE program, part of SFSULIST
* This program tries to solve the problem that many SFS QUERY commands
* always try to perform nickname resolution
*E.G   Q LIMITS FOR USER1
*  Will fail is USER1 is a nick in "userid NAMES" and this
*  nickname has no :localID. tag
* For programs like SFSULIST, nickname resolution should even never
* take place, SFSULIST works from the list of users enrolled in an SFS
* hence each userid it specifies should be take literally, independent
* of what exists in the end-user's userid NAMES file.
*
* As suggested by ALAN ALTMARK, we create a module to NUCXLAOD
* as NAMEFIND and the module exits with rc=32: ie no nick found.
 REGEQU
 USING *,R15
 L R15,=A(32)
 BRR14
 END

The REXX code then basically uses:
 /* For DELETE, QUERY & MODIFY, we avoid Nickname xlation by */
 /* NUCXloading a module as NALMFIND that exists with rc=32 */
 NoNick=(abbrev('QUERY',cmdW1,1) | abbrev('DELETE',cmdW1,3) |,
 abbrev('MODIFY',cmdW1,3) )
 if NoNick then do
address command 'NUCEXT NAMEFIND'
if rc=0 then address command 'NUCXDROP NAMEFIND'
address command 'NUCXLOAD NAMEFIND -NICKSFS'
 end
 address cms cmd
 CmdRc=rc
 if NoNick then address command 'NUCXDROP NAMEFIND'


2008/8/1 Rob van der Heij <[EMAIL PROTECTED]>:
> I had done some programming to help system administration. Part of
> that obtains a list of users to check in SFS. Which users I get listed
> is basically outside my control, and I want the program to be robust
> enough to handle that.
> Trying to understand the strange results, I realized that one of the
> users just happened to match a nickname in my personal NAMES file, and
> the QUERY (in this case) nicely iterated the command for the list of
> users in that nickname. Not nice when you don't want that.
> I felt pretty stupid that I did not disable the (apparent) default to
> search your NAMES file, but found that there is no such option.
>
> I think this is broken. When you want to write robust code, it should
> not casually pick up a NAMES file that happens to be there. In my case
> it just made the output look strange and it made me lookup the syntax
> for Q LIMITS ALL to avoid iterating over all users. This just smells
> like a Trojan Horse attack around the corner.
>
> VMLINK has a NONAMES option to avoid literals to be taken as
> nicknames. SENDFILE and friends would enjoy that too, but I can code
> AT to force no NAMES resolution.
>
> So what's the right way to make this robust? Do I have to save the
> NAMES file and put an empty one there? Or NUCXLOAD some dummy thing as
> NAMEFIND ?
>
> Rob (friday is my security weasel day)
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: Loosing IP after IPL: CTC free

[Ian S. Worthington]

Hi Rob --

My apologies: I'm much more of an MVS person - I'm only pretending to do VM as
a favour, so your questions are a bit over my head I'm afraid.

XAUTOLOG would be defined in the USER DIRECT (this is the PWD 5.3 system),
yes?  TCPIP is defined as below - no xautolog:

USER TCPIP TCPIP 32M 128M ABG
 INCLUDE TCPCMSU 
 OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON 
 SHARE RELATIVE 3000 
 IUCV ALLOW  
 IUCV ANY PRIORITY   
 IUCV *CCS PRIORITY MSGLIMIT 255 
 IUCV *VSWITCH MSGLIMIT 65535
 LINK 5VMTCP30 491 491 RR
 LINK 5VMTCP30 492 492 RR
 LINK TCPMAINT 591 591 RR
 LINK TCPMAINT 592 592 RR
 LINK TCPMAINT 198 198 RR
 MDISK 191 3390 3057 005 530W01  MR RTCPIP   WTCPIP   MTCPIP 

PROFILE TCPCMSU   
  IPL CMS 
  MACH XA 
  SPOOL 000C 2540 READER *
  SPOOL 000D 2540 PUNCH A 
  SPOOL 000E 1403 A   
  CONSOLE 009 3215 T  
  LINK MAINT 0190 0190 RR 
  LINK MAINT 019D 019D RR 
  LINK MAINT 019E 019E RR 
  LINK MAINT 0402 0402 RR 
  LINK MAINT 0401 0401 RR 
  LINK MAINT 0405 0405 RR 


On TCPMAINT 198 there's:

 SYSTEM   DTCPARMS D1 V 71  1BLK 08/08/01 
 ===> 
.*
.* SYSTEM DTCPARMS created by DTCIPWIZ EXEC on 1 Aug 2008 
.* Configuration program run by MAINT at 09:04:12 
.*
:nick.TCPIP:type.server   
   :class.stack   
   :attach.0E40-0E41  
 * * * End of File * * *  

As IP does come up after the IPWIZARD I would guess the device definitions are
ok?  Currently I see:

q ctc 
CTCA 0E40 ATTACHED TO TCPIP0E40   
CTCA 0E41 ATTACHED TO TCPIP0E41   


Is it just a case of adding an XAUTOLOG to the TCPIP defintion?

Apologies for my ignorance.

ian
...



-- Original Message --
Received: Fri, 01 Aug 2008 02:22:19 PM BST
From: Rob van der Heij <[EMAIL PROTECTED]>
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Loosing IP after IPL: CTC free

> On Fri, Aug 1, 2008 at 3:14 PM, Ian S. Worthington
> <[EMAIL PROTECTED]> wrote:
> > I've successfully run IPWIZARD and can connect to my system until I ipl.
> >
> > After that I notice that the CTC is FREE, whereas after IPWIZARD its
"ATTACHED
> > TO TCPIP".
> >
> > I'm guessing this is the cause of the problem. What do I have to do to
make
> > this sticky please?
> 
> Do you XAUTOLOG TCPIP during startup? You should have 2 devices
> attached. Did the DTCPARMS file get built by IPWIZARD ? Can the
> devices be attached to TCPIP? (it does by default an ATTACH where
> real=virt and that breaks when your real device happens to be where
> the sample stack has another device).
> 
> Rob
> 

Re: Dirmaint unknown user id

[Howard Rifkind]

Thanks, this is exactly what I did.

>>> Kris Buelens <[EMAIL PROTECTED]> 8/1/2008 4:18 AM >>>
I think I have seen something like this too in Dirmaint 5.3, I suppose
Dirmaint (better DATAMOVE) will finally help you when it can't
complete a DMDISK/CMDISK due to existing links.
To me this looks like a not unitialized REXX variable.  Maybe the code
contains a PIPE like
   PIPE CP Q LINKS | ... | VAR LinkHolders'
and doesn't test: if Symbol('LinkHolders')<>'VAR' 

To be short: open a PMR

2008/7/31 Howard Rifkind <[EMAIL PROTECTED]>:
> Has anyone seen something like this from Dirmaint.
>
> I'm interested where the user LILNKHOLDERS is coming from.
>
> Thanks
>
> DVHDMC6831E active links held by the following users: LINKHOLDERS
>
>
>
>
> _
> LEGAL NOTICE
> Unless expressly stated otherwise, this message is confidential
> and may be privileged. It is intended for the addressee(s) only.
> Access to this E-mail by anyone else is unauthorized.
> If you are not an addressee, any disclosure or copying of the
> contents of this E-mail or any action taken (or not taken) in
> reliance on it is unauthorized and may be unlawful. If you are not an
> addressee, please inform the sender immediately, then delete this
> message and empty from your trash.
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

_
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the
contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately, then delete this
message and empty from your trash.

Re: Loosing IP after IPL: CTC free

[Rob van der Heij]

On Fri, Aug 1, 2008 at 3:14 PM, Ian S. Worthington
<[EMAIL PROTECTED]> wrote:
> I've successfully run IPWIZARD and can connect to my system until I ipl.
>
> After that I notice that the CTC is FREE, whereas after IPWIZARD its "ATTACHED
> TO TCPIP".
>
> I'm guessing this is the cause of the problem. What do I have to do to make
> this sticky please?

Do you XAUTOLOG TCPIP during startup? You should have 2 devices
attached. Did the DTCPARMS file get built by IPWIZARD ? Can the
devices be attached to TCPIP? (it does by default an ATTACH where
real=virt and that breaks when your real device happens to be where
the sample stack has another device).

Rob

Missing the "nonames" option on SFS commands

[Rob van der Heij]

I had done some programming to help system administration. Part of
that obtains a list of users to check in SFS. Which users I get listed
is basically outside my control, and I want the program to be robust
enough to handle that.
Trying to understand the strange results, I realized that one of the
users just happened to match a nickname in my personal NAMES file, and
the QUERY (in this case) nicely iterated the command for the list of
users in that nickname. Not nice when you don't want that.
I felt pretty stupid that I did not disable the (apparent) default to
search your NAMES file, but found that there is no such option.

I think this is broken. When you want to write robust code, it should
not casually pick up a NAMES file that happens to be there. In my case
it just made the output look strange and it made me lookup the syntax
for Q LIMITS ALL to avoid iterating over all users. This just smells
like a Trojan Horse attack around the corner.

VMLINK has a NONAMES option to avoid literals to be taken as
nicknames. SENDFILE and friends would enjoy that too, but I can code
AT to force no NAMES resolution.

So what's the right way to make this robust? Do I have to save the
NAMES file and put an empty one there? Or NUCXLOAD some dummy thing as
NAMEFIND ?

Rob (friday is my security weasel day)

Loosing IP after IPL: CTC free

[Ian S. Worthington]

I've successfully run IPWIZARD and can connect to my system until I ipl.

After that I notice that the CTC is FREE, whereas after IPWIZARD its "ATTACHED
TO TCPIP".

I'm guessing this is the cause of the problem. What do I have to do to make
this sticky please?


ian 
... 

Ian S. Worthington, MBCS.

me: http://isw.me.uk/ 
photos: http://gallery.isw.me.uk/ 


Dulce et decorum est pro patria mori, sed dulcius pro patria vivere, et
dulcissimus pro patria biber. Ergo, bibiamo pro salute patriae.

Re: Dirmaint unknown user id

[Kris Buelens]

I think I have seen something like this too in Dirmaint 5.3, I suppose
Dirmaint (better DATAMOVE) will finally help you when it can't
complete a DMDISK/CMDISK due to existing links.
To me this looks like a not unitialized REXX variable.  Maybe the code
contains a PIPE like
   PIPE CP Q LINKS | ... | VAR LinkHolders'
and doesn't test: if Symbol('LinkHolders')<>'VAR' 

To be short: open a PMR

2008/7/31 Howard Rifkind <[EMAIL PROTECTED]>:
> Has anyone seen something like this from Dirmaint.
>
> I'm interested where the user LILNKHOLDERS is coming from.
>
> Thanks
>
> DVHDMC6831E active links held by the following users: LINKHOLDERS
>
>
>
>
> _
> LEGAL NOTICE
> Unless expressly stated otherwise, this message is confidential
> and may be privileged. It is intended for the addressee(s) only.
> Access to this E-mail by anyone else is unauthorized.
> If you are not an addressee, any disclosure or copying of the
> contents of this E-mail or any action taken (or not taken) in
> reliance on it is unauthorized and may be unlawful. If you are not an
> addressee, please inform the sender immediately, then delete this
> message and empty from your trash.
>



-- 
Kris Buelens,
IBM Belgium, VM customer support