Re: Generating a CSR from the HMC

[Martin Kline]

Responding to my own question, (tacky?) since I found no references to the
subject in the archives or elsewhere on the web, I didn't want to leave this
as an unanswered question. Here's what I got back from IBM technical support:

It is possible to create a CSR on the HMC but the task is a little  
difficult to see at first.  
  . 
Open the "Certificate Management" task and in the "Create" pulldown 
select "New Certificate"
  . 
On the Certificate Signing panel select "Signed by a Certificate
Authority" and press OK.
  . 
Fill in all the fields and when you press OK it will generate   
a CSR.  If you do these tasks via a browser session, then you can   
save the CSR on the workstation where the browser is run from.  
Otherwise you need to use some removable Media in the HMC to save the   
CSR to.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Generating a CSR from the HMC

[Martin Kline]

Does anyone know how to generate a CSR (Certificate Signing Request) from
the z-Series HMC so I can send it to a certificate authority, which can then
return a certificate I can upload onto the HMC so I can utilize a browser to
access the HMC? 
 
The HMC has some sort of default user-signed SSL certificate that is
unacceptable in our environment. I already know Firefox is capable of
accepting the certificates in our environment, but Firefox is not a solution
our security team will accept.

The HMC seems to have the ability to upload an externally-generated
certificate, but my security team tells me I have to send them a CSR from
the HMC first. Alternatively, the HMC can generate its own user-signed
certificates, but those are considered 'unsafe' by the same security group,
and are hence rejected out of hand by our Windows Explorer configurations. 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP and BPXAS address space spawning

[Martin Kline]

Elardus Engelbrecht said:

>What about limiting it by using the part of OMVS segment of a RACF userid, 
PROCUSERMAX? Or what about THREADSMAX?

That's an interesting idea, and I appreciate the input, but the FTP server
is running with a userid of BPXAS. So the OMVS segment in RACF could apply
to a wider range of applications than just FTP.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP and BPXAS address space spawning

[Martin Kline]

>>snip
1) FTPD gets a connection request on port 21.
2) FTPD sets up the socket.
3) FTPD does a fork(), which is what starts up the BPXAS address space and
usually calls it FTPDn (1<= n <= 9)
4) FTPDn prompts for the user and password.
5) FTPDn then validates that and changes its RACF id (and UNIX identity) if
they are valid.
6) FTPDn then prompts for and executes the user's commands until the client
quits.

>>end snip

The problem address spaces do not change name from BPXAS. When we had an
outage, we had over 390 such address spaces. 
 
A little experimentation: 5 BPXAS address spaces are waiting. I connect to
FTP from my PC. No new address spaces. Netstat shows my workstation has a
connection to the FTPD1 address space on port 21. I sign on. The name of one
of the BPXAS address spaces changes to be my userid. The TCP/IP session is
still with FTPD1. I enter 'QUIT' on the FTP session. The workstation
terminates FTP, and the address space on the on the mainframe is renamed to
BPXAS again. 

I can verify that the BPXAS address space is processing the signon request,
because when I enter an invalid password, the error message comes from one
of the BPXAS address spaces. What this indicates to me is that FTPD1 manages
the port for the control session, and passes messages to and from the BPXAS
address space.

This still leaves me with the main problem. Numerous BPXAS address spaces
can be created in a short time, resulting in an address space shortage. the
address spaces will stick around until they reach the SMF wait time limit. I
have documented as many as 90 such address spaces being created in just 60
seconds. I do not, however, see that any user signed onto those sessions, so
the BPXAS address spaces are just waiting for userid/password or something else.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

FTP and BPXAS address space spawning

[Martin Kline]

How does FTP determine it needs to spawn additional server address spaces,
and is there any way to limit that expansion aside from the maximum number
of address spaces applicable to all users? Is there any way to automate the
termination of those address spaces besides job wait time?
 
Our situation is that a flurry of clients connect to the FTP server at about
the same time. FTPD1 spawns upwards of 25 BPXAS address spaces (BPXP024I
BPXAS INITIATOR STARTED ON BEHALF OF JOB FTPD1) within a matter of a few
seconds. Sometimes this number may be much higher. 
 
There seems to be no control over the spawned address spaces. They simply
stick around until they reach the SMF-defined JWT, then they go away.
Occasionally the added address spaces result in IEA602I ADDRESS SPACE CREATE
FAILED.  MAXUSERS WOULD HAVE BEEN EXCEEDED. 
 
None of the FTP configuration options seem to apply, since the waiting
address spaces have no active connections. Any suggestions besides just
increasing max address spaces and hoping I don't reach the new limit?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How does VTAM handle duplicate MODEENT names in a logmode table?

[Martin Kline]

John Chase:
>Are the entries duplicated? Or just the labels?  Seems that if the
>entries are duplicated (i.e., all parameters are identical in each
>entry), the duplicates are superfluous and can (should) be eliminated.
>To see the effect of duplicate labels, look in the ESD to see which one
>is addressed.

I should clarify. These are duplicate names for non-identical logmode
entries in the same logmode table. For example, One entry for DSILGMOD has
FMPROF and TSPROF both set to X'02'. The second entry called DSILGMOD has
them both set to X'03'. The entry in ISTINCLM in SYS1.SAMPLIB has both
fields set to X'02'.


>Seems that it should be simple enough to modify a private copy of the
>MODEENT macro to generate labels as apparently done earlier.

Yes, I could do that, but I would still have a nagging loose end about
duplicate names in the logmode table. What is the chance IBM would change
the lookup logic some day?  The presence of a modification to the MODEENT
macro that specifically eliminates duplicates gives me enough reason to be
concerned.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How does VTAM handle duplicate MODEENT names in a logmode table?

[Martin Kline]

Allen:Why not just remove the entries that duplicate those in the IBM
ISTINCLM
from your load module.
That way the IBM load module (and associated LOGMODE entries) will be
found in the "normal" search order.
 
Thanks, but then I wouldn't be able to find any of IBM's entries. The
modified ISTINCLM load module has the same name as the original, which makes
the original load module inaccessible, and is my original issue with EE.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How does VTAM handle duplicate MODEENT names in a logmode table?

[Martin Kline]

For clarification, the original problem I am dealing with is that I
inherited a system where the implementation of EE was incomplete. In trying
to enable EE, VTAM issued an IST663I message with sense 08210002, further
explained in an IST264I message indicating "REQUIRED LOGMODE NAME CPSVCMG
UNDEFINED". A little research revealed that CPSVCMG is used for CP-CP
sessions, and is required to be in the ISTINCLM module for EE. 
 
Further research revealed that CPSVCMG does exist in IBM's version of
ISTINCLM, but that we have another version of ISTINCLM located ahead of
IBM's version in the concatenation for VTAMLIB. With luck this version of
ISTINCLM modified from an original. This custom version of ISTINCLM has over
550 logmode entries. IBM's current version has fewer than 100 entries. So,
yes, this version has been modified significantly, and no, there will be no
luck in this adventure.
 
Just to make things more fun, I discovered that the source for this modified
ISTINCLM load module was missing. The date from the link edit data shows it
was last linked in 1993. (That sinking feeling starts.) I spent a few hours
throwing together some REXX code to parse the load module, which is just a
series of control blocks, and rebuilt new source macros. The modern macros
generate larger table entries that include new fields for APPNCOS and a few
other items, but that's ok. The source generates a compatible module. (Chris
Mason is probably the only person who would pick up on this subtlety, but I
did add valid APPNCOS values for every entry in the reconstituted source.)
 
However, when I assembled the source I got some duplicate labels. At some
point in the past, the MODEENT macro was modified to use the value of the
LOGMODE= operand as the label. References I found indicate this was done
specifically to prevent duplication of LOGMODE entries. It doesn't actually
prevent duplication. I simply causes an  assembler error, which can be
ignored if I want to link the module anyway. Why didn't IBM want duplicate
entries? Why was it important to discourage them?
 
Not being one to like loose ends, I hoped to remove the duplicate entries.
My first thought about the duplicates was that they might have been copied
inadvertantly, and that all of the fields for the duplicates would match.
They don't match. Remember, there is no luck on this adventure. (That
sinking feeling gets a little stronger.)
 
The next solution would be to remove the entries which are not used by VTAM.
So, that prompted my question about whether VTAM uses the first, last or a
random entry. 
 
 
Just to further complicate things, the customer who wants EE implemented
tells me that EE was working between his system and our test system last
year. So I investigated. I found that the test system is using the default
IBM ISTINCLM LOGMODE table, and does not have a customized version of it in
place. The customer complains that the test and production systems are
supposed to be identical. (That sinking feeling is beginning to turn to mild
hysteria. What next?)
 
 
Using the information Chris Mason provided, that VTAM searches ISTINCLM as
well as any specified MODETAB for a LOGMODE, I think the ideal solution in
my situation would be to rename the existing modified ISTINCLM load module
to something else and to modify all entries in VTAMLST that currently have
no MODETAB entry so they specify the renamed table. Ultimately, I should
also rebuild the modified table with the reconstituted source, but then I
still have to resolve the duplicate entry question. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How does VTAM handle duplicate MODEENT names in a logmode table?

[Martin Kline]

(Reposted by request from Chris Mason)

Sorry, I've no idea regarding whether the first duplicatly named entry is
taken, the last duplicatly named entry is taken or some random selection. If
my arm were twisted, I'd say the first. I don't believe VTAM expects to
handle that many mode table entries so I don't expect a complex technique
such as a hash table is used and I can't see why VTAM should deliberately
suspect duplicates and make sure it used the last.
I expect you are already aware that IBM *always* considers the ISTINCLM mode
table in SYS1.VTAMLIB to be concatenated after any private mode table
(MODETAB=). This would tend to suggest that VTAM simply takes the first mode
table entry having a particular name so that you can respecify a mode table
entry from ISTINCLM in a private table if you want to. I think I've always
simply assumed that and I can't recall ever having checked that.
Incidentally, this use of ISTINCLM concatenated after the MODETAB name means
that ISTINCLM is not a default for the MODETAB operand as is usually - and
quite incorrectly - stated.
I expect you are also aware that the DYNMODTB start option was designed for
the specific purpose of having a private mode table which could be used by
any secondary LU or representation of a secondary LU especially when the
representation of a secondary LU is a dynamic CDRSC. I'm not sure whether or
not that may be relevant to the original problem you were trying to solve.
Prior to the availability of the DYNMODTB start option - with great
reluctance - VTAM gurus were obliged to suggest modifying ISTINCLM - shock,
horror! With the availability of the DYNMODTB start option, they could all
forget that they had ever had such an heretical[1] thought!
You might like actually to explain the original problem which led you down
this perilous path. There has to be a better solution to whatever it is.
If you want a definitive answer about how VTAM handles duplicate mode table
entries in the object module, I expect you are going to have to sweet-talk
your IBM VTAM support into activating a request to development - and hope
for the best!
Incidentally, I discovered that I needed to create Unformatted System
Services (the real USS) tables with assembler errors in the sections where I
coded complex 3270 data streams. As you did, I checked the object code and
found everything was there I wanted to be there even though I had to swallow
some insulting messages from the assembler!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

How does VTAM handle duplicate MODEENT names in a logmode table?

[Martin Kline]

The title says it all, but I'll lay out the details so you can understand
why I want to know. 

We have a modified version of ISTINCLM located in the VTAMLIB concatenation
ahead of the default in SYS1.VTAMLIB. That member is missing the CPSVCMG
logmode needed for an EE connection. The CPSVCMG logmode can be found in the
default IBM ISTINCLM member. There is no source for the customized member,
but I wrote a quick REXX exec that can regenerate a compatible source member
so I can integrate additional entries from the IBM source.
 
When I reassemble the source I get some duplicate labels - 21 in all.
Actually, they are duplicate MODEENT LOGMODE=name entries. I can see from
the current load module that duplicate entries really do exist. Part of the
problem is that they are not actually complete duplicates, as some of the
other fields do not match. Therefore, that prompts the question of how VTAM
is handling this. Does VTAM use the first matching entry for the requested
name in the table? Does it use the last entry? Does generate a hash table at
load time, and select one entry based on some other variable?

I'd like to clean up the source to remove the unused entries, but without
knowing which entry VTAM uses, I don't know which to delete. On the other
hand, I could leave the duplicates in place, ignore the assembler errors and
create a new load module with the additional IBM-original entries added, as
long as I can be assured that doing so won't alter the way VTAM handles the
duplicates. Of course the second option leaves me open to some future issue
should VTAM's handling of duplicates be changed.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Calculate Tape Bytes to Tracks

[Martin Kline]

>>BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset 
parameters.

>Sometimes?
>When is it not?

Besides having to be a multiple of LRECL for FB files, another situation where 
half-track blocking is bad is for a PDS with many members sized at just over a 
half track. In this case, wouldn't each member waste slightly less than half a 
track with one half-track block and one short block? The same would apply for 
a file where DISP=MOD adds a little over 27998 bytes each time new data is 
appended. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: tso session timeout

[Martin Kline]

>Please explain 'accounting in SMF records'. Does that means some SMF 
>records were not written at all if TIME=1440 is used?

>Where is that history trivia documented?

>Just (very and very) curious... ;-D

ISTR that in MVS 3.8 the initiator task checked the time value for 1440 before 
recording/saving the accumulated CPU time for the job step. I don't believe it 
works that way any more. It may have been documented or not, but it was at 
least a fairly well known 'feature'. I don't think the anomoly actually 
prevented 
the SMF records from being written. They just didn't show any CPU time.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

USSTAB Message Corruption Revisited

[Martin Kline]

Last August I worked with Chris Mason on a USS table issue. A brief recap: 
TCPIP provides symbol substitution in USS messages which contain system 
symbols and certain defined character strings that start with two or more '@' 
characters. VTAM also provides symbol substitution for defined character 
strings, but not for system symbols. With 3270 data stream formats, certain 
control characters can be mistaken for the ampersand and at-sign characters. 
Set buffer address (SBA), erase unprotected to address (EUA), Repeat to 
address (RA) and start field (SF) can potentially cause this problem. I ran a 
number of tests on my sandbox, and demonstrated that, for example, a SBA 
for row 14 column 1 on a 80-character wide screen results in a hex address 
of '5050', which is a double ampersand. If this were followed by the 
characters 'SYSNAME IS TESTXYZ', and the system name were 'TST1', then 
the SBA field would be corrupted with the second x'50' being replaced with 
x'E3' followed by the characters 'ST1'. The resulting display would put 'ST1 IS 
TESTXYZ' at row 14, column 20. I saw that as a problem. 

I opened a problem with IBM back then, and after a long, slow process, I 
managed to convince them that this is not how the function should work. This 
month I got a usermod to test. It did not address this specific problem. All it 
addressed was the truncation of data. In the example above, the text is 
actually shortened to match the length of the substituted value, which can 
adversely affect alignment on a formatted screen, even when the substitution 
was intended by the programmer. The second part of the fix was to update 
the documentation so that the handling of system symbols and TCPIP 
variables is more specific. System variables are ALWAYS replaced in the TCPIP 
environment and other TCPIP variables are only replaced when requested by a 
parameter on the USSMSG macro, but that's not how the documentation 
reads without the changes. 

No attempt was made to address unexpected variable substitution, and I have 
had to open a second new problem to initiate a requirement. The requirement 
is that the code should work as expected and not astonish the programmer 
with unexpected results. For our environment I use macros to generate 3270 
control codes, and I wrote a program that reads a generated USS table to 
display the message 10, so I can verify that it appears as expected. It's great 
for testing, but when TCPIP might randomly alter the data after I implement in 
production, it can get really frustrating.

In summary, you can expect the documentation changes within a few years, 
and you might see a PTF or two some day as well. In the meantime, if you 
think something might be wrong with your USS tables, call IBM. They would be 
happy to walk you through the process of checking every SBA, EUA, RA and 
SF for special characters and help you build a work-around.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX and VTAM command responses

[Martin Kline]

>I have a rexx that issues console commands and writes the responses to a
>dd after using getmsg to retrieve the response. Everything is good for 
>MVS commands and JES2 commands if L=Z is included.  Is there a similar 
>option for VTAM commands? For D NET,, I am only getting: 
>IST097I DISPLAY ACCEPTED
>I've tried adding the CART parameter to my emcs console and the getmsg 
>with same results.

I believe you are actually getting all of the messages in one getmsg request. 
for example the folloowing statement,
msgrc = getmsg('MSG.','SOL',,,3)
can return multiple messages in MSG.1, MSG.2, etc. with the count of 
messages stored in MSG.0.

Check the stem variable you supply to see if you are getting all of the 
messages at once.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Overlap Error

[Martin Kline]

>Does somebody has thought on that..?? i still see option to breakdown step
>into 3 separate steps to make sure STOW open and close data everytime
>and we don't see overlap error..

You can resolve the problem via JCL and leave the program alone. Have the 
output be three or more separate temporary data sets. Tnen follow that step 
with steps to copy the temporary data sets one by one into the original target 
PDS. Use DISP=OLD to ensure no other job/user is writing to the same PDS.

If you can be certain no one else will be updating it, then DISP=SHR will 
suffice. This would be typical, for instance, if the output PDS was allocated 
to 
a long-running task or to multiple tasks, such as a JCL library owned by the 
scheduler using it as read only, or ISPF panel/message/skeleton libraries 
allocated to many TSO users for input.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use

[Martin Kline]

>You do not give them access to the target or distribution libraries.

>That would prevent APPLY/ACCEPT.

But you would give the same people update access to the PTS and CSI? 
Wouldn't that just make it possible for a determined person to create or 
modify a PTF so that the authorized person can implement it for them? 

For example, it would be fairly simple for a trained person to modify SMP input 
for a HIPER PTF to add JCLIN and a new CSECT that replaces almost any SVC 
on the system. They receive it to the PTS, the systems programmer installs 
the modified PTF, and unknowingly implements whatever security hole the 
originator wants. 

For me, the SMP libraries are at most read only for anyone except the systems 
programmers. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Overlap Error

[Martin Kline]

Of course, after sending the previous post, I found the reference right away. 
>From DFSMS Using Data Sets:

To add additional members to the PDS, follow the procedure described in   
Figure 112 in topic 3.7.4.1. However, a separate DD statement (with the   
space request omitted) is required for each member. The disposition should
be specified as modify (DISP=MOD). The data set must be closed and
reopened each time a new member is specified on the DD statement

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Overlap Error

[Martin Kline]

>Thanks !!! Yes that's correct we have traditional PDS and not PDSE... I
>thought same & even  suggested  application programmer to split the writing 
>to members however could not prove it & again they had been using
>DISP=OLD which put my thought in question...
>
>There JCL look like this (current)..
>
>
>//step1 exec pgm=x
>//sysprint dd sysout=*
>//dd1   dd disp=old,dsn=xxx(member1)
>//dd2   dd disp=old,dsn=xxx(member2)
>//dd3   dd disp=old,dsn=xxx(member3)


I didnt' find an exact reference quickly, but I believe you will run into 
trouble if 
the application opens all three outputs DD1, DD2 and DD3 when xxx is the 
same data set. DISP=OLD only protects this job step from some other job, not 
fro itself. Suppose you open DD1 first, then open DD2 before closing DD1. The 
starting TTR for DD2 may (since I couldn't find the reference) point to the 
same location as DD1. The writes get overlay one another. The STOW is not 
issued automatically until you close each output file. When the DCBs are 
closed, the STOWs get issued, with the same TTR for the both members. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Message during logon

[Martin Kline]

>When I log on to tso I receive the following messages after the ID has
>been entered:
> 
> IKJ56700A ENTER USERID -
>X123456 
> IKJ56712I INVALID KEYWORD, : : 0
> IKJ56703A REENTER THIS OPERAND -

Besides the emulator, the USS table could be bad. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: tso/e logon panel

[Martin Kline]

Check the section titled "Customizing logon panels and logon help panels" in 
the TSO/E Customization manual.

>I have seen in the past references to the ability to change the
>TSO/E logon panel. I attempted this quite some time ago but
>put it off. I cant recall what the TSO/E module is. I saw that
>someone had disabled the new password field. We have a 3rd 
>party software that changes the password for TSO users. I would
>like to revisit changing this screen but cant recall where to start.
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Need tool to zap core

[Martin Kline]

>>Never resulted in an IPL with my own such code . :)

>There is always a FIRST time combined with Murphy's law, then you'll be 
>zapped by your boss. ;-D

I've always interpreted that 'first time' reference to only include things that 
actually happen. For example: programming errors occur, so there must have 
been a FIRST program error, or bad vendor products are sold, so there must 
have been a first bad product. But to assume something bad that has not 
happened will eventually happen is a pessimistic view of things. Although less 
likely to occur, I could use the same logic to assert that there will be a 
first 
time for the planet Earth to suddenly leave its orbit around Sol, change to 
antimatter, and instantaneously transport itself across the universe. The first 
time that happens, my boss won't be very happy either. 

Nevertheless, part of my responsibility in undertaking such a potentially 
dangerous task is to do everything I can to ensure there is no first time 
failure 
and subsequent unpleasant boss zapping. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: URGENT - PROBLEM WHILE STARTING JES2

[Martin Kline]

>when the system start jes2 it failed  and i get the following message :
>   *16.15.02  *IEF431E ZERO QMPA POINTER FOUND. SWA MANAGER 
>REASON CODE=3C

Make sure all of the datasets referenced in the JES2 JCL are cataloged in the 
master catalog.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Need tool to zap core

[Martin Kline]

>Martin - surely you have missed out the last step :

>"Make it authorized. Switch to key zero. Verify the storage. Alter the 
>storage. Switch back to user key. Exit..er...IPL"

Never resulted in an IPL with my own such code . :)  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Need tool to zap core

[Martin Kline]

>I have a need to zap core, but my client does not have OMEGAMON.  I 
>searched the CBT mods tape and came up empty.  What we're trying to do is 
>a SETPROG LPA,ADD, but of course, there's a vector table that needs to be 
>updated with the address of the new module.  This is not an SVC, so my only 
>recourse to install this without an IPL is to zap core.  Are there any 
>freeware 
>tools out there for zapping core?

In a pinch I've written a short assembler language program to do that when I 
was dealing with common storage. Make it authorized. Switch to key zero. 
Verify the storage. Alter the storage. Switch back to user key. Exit.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JES2 Job Separator

[Martin Kline]

>Can anyone give me an advice if there is a JCL parameter to supress JES2 >
>Job Seperator (JES2 local host Printer, SEP=YES/NO) being printed only for 
>output that created from a particular batch job?


I am not aware of such a parameter, however, and this depends on your 
printer configuration and software, you may be able to define a second printer 
definition for the same device, assign it a unique parameter such a 
destination, set the SEPPAGE parameter to NONE, and send your output to 
that definition instead of the existing one. You could also use the existing 
definition, assigning a specific class (or other work-selection parameter) to 
the output, and switch the printer via operator commands - setting the WS 
criteria to match the SEPPAGE requirement.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Fastest branch instruction

[Martin Kline]

I know "it's the one not taken!". But of the B, J, or BR, can they be ordered? 
I 
am 99.9% certain that having the branch address in a register is the fastest. 
But is it significant enough that I should dedicate a register for it? I'm 
asking 
because I'm reoptimizing some code which is very heavily used. So heavy, 
that a 1% improvement is worth while. I am currenly holding 4 different 
addresses in registers to speed up branch processing in my main loop.  This 
loop is basically compressing blanks using a primitive RLE algorithm.


I ran a number of tests on our z9, but after a few tries, decided the choice 
between B, J and BR is trivial. My tests ran through 12 different strings 1 
million times, and ran each test 5 times. Using simple CLI, BE, LA, BCT 
searches was much slower than the SRST instruction. Like the CLCL you are 
using, SRST scans the data for you in one instruction, and you don't have to 
manage your own loop. That cut 50% off the reported service units in my 
tests. When I changed from BE and BNE to JE and JNE, I actually increased 
service units by about 0.1 percent. When I changed to BER and BNER, I also 
showed a slight increase - probably because I had to prepare the destination 
register each time though the million trials. 

Using TRT to find data doubled the service units. Using TR to mainpulate the 
data so a second SRST could find the non-blanks increased the times by more 
than double. 

Conclusion: Change the scan-for-blank loop to use SRST. You should get a lot 
of mileage out of that one change.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: GDPS Distance Impact on Sysplex Response Time

[Martin Kline]

>The dumb question of the day is, what's the point?  Unless they need the
>floor space, are phasing a dc relocation, or want to eventually build a quasi-
>GDPS (which means moving / mirroring tape, DASD, CFs, etc.), this is a 
>costly exercise in futility.

I can't argue with that conclusion. However, I was not asked for my opinion. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: GDPS Distance Impact on Sysplex Response Time

[Martin Kline]

Considerations for Multisite Sysplex Data
Sharing

It has a lot of details about the impact of the distance between sysplex
sites.


Thanks for that. Yes, I recently located that manual, and am trying to decide 
how to distill this into either an "It will be ok" or a "I wouldn't if I were 
you" 
answer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: GDPS Distance Impact on Sysplex Response Time

[Martin Kline]

Based on the information provided, this is a bad idea.


I was not asked for my opinion, but I certainly understand yours.


1) It introduces SPOF (single points of failure).


Until proven otherwise, no additional SPOF are added to the production 
systems. The development systems are considered to be expendable (but no 
one asked the developers about that).


2) A new datacenter should have its own customer number and the 
development MSUs should be reset to zero and calculated at the most 
expensive tiers (0 - 345), instead of at the cheaper clip level.


The belief of those who make the decisions here is that maintaining a single 
sysplex will keep the licenses as they are.


3) channel extension and teleco charges - don't they make it a bad idea?


That depends on distance and pricing. We're looking at cross-town sites less 
than 40 km away.


What exactly are they trying to accomplish? At my last company, I did the 
opposite of what you are trying to do...I merged a development datacenter 
into the primary. Saved a fortune in software $$$ and improved development 
and testing response times and batch throughput substantially. Not to 
mention, reduced network traffic.


We, the technicians who implement the ideas of those who make decisions 
and pay checks, are not asked/allowed to participate in such decisions.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

GDPS Distance Impact on Sysplex Response Time

[Martin Kline]

We have a sysplex with four processors, two of which run production work 
with development work on the others. In their quest for trivia, my 
management wants to know the impact to production if we move the 
development processors to a second site, leaving the coupling facilities, DASD, 
VTS and primary network all on one site. 

I suspect this is a function of how much production data is being touched by 
the development systems as well as just the handshaking, messaging, etc. 
across the entire sysplex. I also suspect it affects some online transactions 
and batch work much more than other work. In addition, they want to know 
how much greater the impact is if the other site is twice as far away. 

And, just to make this interesting, they want an answer tomorrow. Actually 
they would like it yesterday, but tomorrow will have to do. I've been reading 
several manuals, and I think the answer they should get is 42. 

Does anyone have any suggestions on where to concentrate my efforts (only 
those that won't get me fired, please)?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Friday thought - a couple of SUBSYS= subsystems for discussion.

[Martin Kline]

>I wonder about doing something "hinkey" in OPEN. OPEN can open multiple
>DCBs in a single SVC. So, I wonder if it does it them sequentially. If so, I
>wonder if it would be possible to dynamically add my DCBs onto the end of
>the list. Probably not something that would be long term viable.

Since the environment may be a little sticky for issuing a secondary OPEN 
SVC, how about altering the SVC return address in the RB (I think) so it 
returns to your code but in the user's original state? The subsystem code 
could first gather all the info it needs and put pointers into the user's ACB 
or 
DCB. Then when the original OPEN SVC returns, finish up with the secondary 
OPEN calls, fix up the ACB or DCB, and finally return to the actual user's SVC 
return address. Subsequent PUTs or WRITEs branch to your code, which does 
its thing. Handle the CLOSE SVC like the OPEN. I'm not sure about the 
environment during termination processing though (abend or exit without doing 
close), so the CLOSE code may still have to check for that situation.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Friday thought - a couple of SUBSYS= subsystems for discussion.

[Martin Kline]

>I think we could use the GPSAM routines from the CBT tape to create the
>TEE function.

Both versions of this (CBT files 290 and 648) appear to have been written in 
1982. I haven't tried using the code on our z/OS 1.9 system, but they use 
some questionable means of locating and modifying control blocks. They may 
or may not still work, as some control blocks may have moved. Although the 
basic function of this code appears to be valid, there are other (and 
sometimes documented) means of performing these functions. A little bit of 
modernization might be in order - such as allowing the subsystem to 
dynamically define itself, but this code does provide a good start.

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Friday thought - a couple of SUBSYS= subsystems for discussion.

[Martin Kline]

I can think of a couple other solutions using out-of-the-box methods, but 
neither is as clean as what you're proposing. You'd need a minimum number of 
subsystem routines - JCL processing, allocation, open and close, and maybe 
another couple. At OPEN time, issue OPENs for the related files, update the 
DCB (or ACB) with appropriate info including your PUT/WRITE interface 
address, and any data that the original program may need, like LRECL, RECFM. 
It would have to recognize move and locate modes, and possibly have to build 
a buffer pool in case the program wants to do a freepool. You could almost 
ignore exit processing (have to think about that one). As you suggest, on the 
output side, the two (or more?) files could be QSAM or VSAM. The entire 
process could be as simple or as complex as you want. Possible additions 
include filtering one of the output files for certain records or for every nth 
record, or connecting to an IP port for one of the outputs, or sending filtered 
data to the console. 

OK - wait - I'm supposed to be working here, not daydreaming. 



The TEE subsystem is inspired(?) by the UNIX tee command. The tee
command reads its "stdin" and sends it to a named file and its "stdout". The 
main use is to be able to read the stdout on the terminal and log it to a file. 
I 
use it simiar to: "make | tee make.listing" which lets me keep the make 
output in a file and watch it also. So I considered that something similar for 
JCL might be useful. I thought of something like:

//SYSPRINT DD SUBSYS=(TEE,'FILE,SYSOUT')
//FILE DD DSN=OUTPUT.FILE,DISP=(NEW,CATLG), ...
//SYSOUT DD SYSOUT=*

The program opens SYSPRINT. The TEE subsystem then opens DDs FILE and 
SYSOUT. Every record written to SYSPRINT also goes to FILE and SYSOUT. 
Why do this? In order to write the output to a file while, at the same time, 
being able to see what is being written by using SDSF. Our programmers often 
write reports to SYSOUT in order to monitor them, but then need to use SDSF 
to put them into a disk file. An advanced implementation might want to be 
able to write to VSAM (KSDS or ESDS) instead of just writing to a sequential 
file. Or use this to "fan out" a dataset so that a GDG version is written to 
tape 
whereas a non-GDG version is written to disk.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?

[Martin Kline]

I'm just throwing this idea on the table, and expect either little interest or 
strong opposition. What if catalog support allowed ALIAS names to exceed 44 
characters? 

First, yes, I did search the archives. Second, Yes I understand the 
implications.

The cost and impact of supporting long alias names (though still not small)
would be considerably less than the cost of expanding actual data set names. 

I just came up with this before my second cup of coffee, so the idea is still 
cooking. 

Last time I checked, the impact to IDCAMS and catalog records would mostly 
involve relaxing the syntax restrictions. The impact to JCL conversion would 
be similar. JCL processing would have to allow for longer names prior to 
catalog search, and actual (shorter) names could be stored in places like the 
JFCB. Certain SMF records might have to change. 

Expanding a little bit, SMS processing could potentially define long names as 
aliases automatically and generate actual names using some schema like 
temporary name  generation. Doing this would mask the effort of mapping long 
and short names from the end user, effectively allowing long names without 
any special user changes. 

As for a business case to get IBM to implement- oh well. It was just a thought.

As a local business case - There are those twice-a-year instances when users 
can't seem to create a meaningful and acceptable name in under 45 
characters. So, I guess I won't be creating any usermods today . . . but if I 
still had those microfiche . . .


>Subject: Re: IDC3203IITEM 'xxx' DOES NOT ADHERE TO RESTRICTIONS 
>From: "McKown, John"  
>Reply-To: IBM Mainframe Discussion List  
>Date: Mon, 14 Dec 2009 10:10:14 -0600 

>Not likely to be done. That would require a complete rewrite of the VTOC.
>The DSN is a 44 byte hardware key in the VTOC. I cannot imagine how IBM 
>would ever compatibly change the DSN length. Short of creating an entirely 
>new, incompatable, interface where something (perhaps in the record which 
>points to the VTOC) indicates that this is a "new VTOC" formatted volume. 
>And that would require updates to the entire world. Who's gonna pay? I'd 
>rather they support SAN DASD in z/OS (which means FBA).

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Now is time for banks to replace core system according to Accenture

[Martin Kline]

Mark Yuhas said:
>A long time ago in a galaxy far, far away, Accenture was Arthur Anderson 
>Consulting.  My company contracted with them to assess the status of our 
>technology and its direction.  While it was a foregone conclusion they would 
>recommend a shift to UNIX, I was totally underwhelmed by the 'mainframe 
>acumen' of their staff.  Arthur Anderson used this venture as an OJT exercise 
>for their staff.  Their staff probably just finished their BA and or 
>equivalent 
>thereof which included a working knowledge of
>Windows and the Internet.   Further, the vast majority of their survey
>and results came from cutting and pasting from articles on the Internet.

Wow. I don't recognize your name, but I went through exactly the same 
experience with the woefully inexperienced staff from AA. They burned $35M 
of the company's money before being booted out the door. Yet, they were 
such good salesmen, that management refused to listen to us techies when 
we complained about AA's incompetence.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Reentrant Programs and Protected Storage

[Martin Kline]

>I grew up believing that if a program is link edited as reentrant AND
>it is loaded from an authorized library, it gets loaded into 
>protected storage.  That is what the manual says, too.  However, that 
>is not what appears to be happening.

>We are on z/OS 1.10.  There is a non-reentrant program which, when 
>executed via JCL from an authorized library, fails with a S0C4.  When 
>the failing program is physically copied to another library and 
>executed from there, it runs correctly.  This is entirely repeatable.

Did you browse the load library directory and verify the program is not linked 
as RENT? Based on what you've written, it sound like the system is treating 
the program as if it had the RENT attribute.

BTW, One reference to how laoder handles RENT is in MVS Program 
Management: User's Guide and Reference:


RENT  
The module is reenterable. It can be executed by more than one task at
a time. A task can begin executing it before a previous task has  
completed execution. A reenterable module is ordinarily expected not  
to modify its own code. In some cases, MVS protects the reentrant 
module's virtual storage so that it cannot be modified except by a
program running in key 0. These cases include programs which the  
system treats as having been loaded from an authorized library, and   
also programs running under UNIX unless a debugging environment has   
been specified.   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: user-written MVS subsystems

[Martin Kline]

>I started examining the code and observed that he doesn't use the services
>described in the books like "Using the Subsystem Interfaces", Chapter
>4, "Writing Your Own Subsystem", but instead he inserted the control blocks
>like SSCT and SSVT using GETMAIN and CS (taking care of parallel writers)
>and moved the function code into the CSA using MVCL etc. - all fine code,
>but no IEFSSI and other macros anywhere.

I wasn't aware anyone was working on my old code. ;) 

If it was written in the eighties, there was little documentation and fewer 
macros to support subsystem interface. I remember spending many hours 
pouring over microfiche to determine how this stuff worked, and being 
disappointed that any IBM API would have such poor documentation. But I did 
learn a lot about internals. SVC screening was similarly poorly documented, 
and last time I checked, it still was.

The code may continue to function indefinitely, or it may start giving you fits 
with the next upgrade or PTF. If it were my code and I still supported it, then 
I'd rewrite it to use the 'preferred' macro interfaces. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Receving PTFs for measuring workload that can be processed by ZIIP engine

[Martin Kline]

> UA23218  NOT RECEIVED  PTF  

This PTF is for FMID HBB7709. On our system, that is superceded by HBB7740. 
I don't know about the rest of your system levels, but if the PTFs are for 
related FMIDs of multiple releases, then SMPE should receive only the ones 
that are applicable to your system. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Weird INTRDR with REXX JCL steps

[Martin Kline]

>It appears that when I try to submit the second job through the INTRDR the 
>SYSTSIN in my REXX step of the second job gets lost.

Although you have already found a work-around, I suspect you were not 
writing all of the lines from your REXX code. Did you also close the OUTFIL DD 
by including the FINIS option? Did you write it to a file to verify the data?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: An Alternative Modest PARM Proposal

[Martin Kline]

(Tiring of people arguing in circles and getting nowhere)

Let's take a poll. Suppose for the sake of argument that I had in my posession 
a set of system modifications which allowed specification of EXTPARM, which 
let you specify program parms of up to 32767 characters in length, and that 
you could obtain this modification for a small fee. Who would be interested in 
using it? Who would refuse to use it? 

What if you could specify in your parmlib the list of programs which could be 
invoked with this parameter? Would you use it then? After all, aren't we really 
talking about a limited number of potential uses at any given site?

Take it a step further. Suppose IBM supplied this capability with the next z/OS 
release. Also suppose that you could enable or disable the functionality via a 
parmlib value as well as specify the programs that were eligible for use. Would 
you be interested then?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: An Alternative Modest PARM Proposal

[Martin Kline]

This does not have to be a 'all-or-none', or 'my-way-or-the-highway' issue.

Assume the some programs can accept JCL-format parms of more than 100 
bytes. Also assume that some programs cannot accept such parms. Also 
assume you don't want to force program changes.

So what's the issue? In some cases, you want to be able to pass more than 
100 characters as a JCL parm to a program that is capable of handling it.

I believe it's been discussed already, but why not just request an additional 
JCL parameter, such as PARMX or EXTPARM, or whatever, that has the 
following restrictions: Cannot be specified along with PARM, and a maximum 
length of 32767 characters, with the same formatting requirements as the 
PARM parameter. Document the restriction that passing more than 100 
characters to a program should only be done when the program supports it. 
The resulting data as presented to the called program would be the same: 
pointer to HW length followed by data of that length. So, coding PARM='RENT' 
or PARMX='RENT' results in the same data. 

I have no requirement for passing more than 100 characters in the parm for 
the linkage editor or HLASM. So, I could code PARM or PARMX. It makes no 
difference. I don't even care if these two programs ever support more than 
100 characters. 

However, I may need to pass more than 100 characters to some program, 
such as the COBOL compiler. First, I have to know that the compiler supports 
it. Second, I need the JCL support. Today, assuming the called program 
supports the parm, if I want to create a simulated parm, I could front-end the 
compiler with REXX or assembler, building the long parm list as needed. With a 
new JCL option, I could bypass the front end process.

Finally, what about users who pass more than 100 character parms to 
programs that are not coded to handle them? That's why you document "Don't 
do that, or you get unexpected results." What happens now if I pass an 
invalid parm to a program?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Model-204 and SMS

[Martin Kline]

>Is there any reason Model-204 should not be on SMS managed volumes?

I am not the M204 support here, but as far as I can tell, all of our M204 files 
are on SMS-managed volumes. So, I'd say there's no reason they cannot be 
SMS-managed.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How is SNA Sense 087D0001 caused by RUSIZES in logmode?

[Martin Kline]

I may have been mistaken. Unfortunately, I inherited the network 
responsibilities from someone else. That's my excuse, and I'm sticking with it. 
It appears that my predecessor left several versions of similar, but 
significantly different logmode tables and source members laying around. The 
failing module not only differered in the RUSIZES, but was also missing the 
APPNCOS specification on the one failing logmode entry. The source I 'fixed' 
had APPNCOS included, so when I replaced the load module, I inadvertantly 
added the missing parameter, and it started working. Sorry if I led anyone on 
a wild goose chase.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

How is SNA Sense 087D0001 caused by RUSIZES in logmode?

[Martin Kline]

We've had a long-standing issue with a particular VTAM logmode not working 
across systems. The logmode is ALTMOD45 used by 3270-type LUs with a 
primary screen size of 43x80 and alternate of 27x132. This logmode works fine 
for TSO and for CA-TPX on each system. However, when the user connects 
to system A and tries to access TSO or TPX on system B using this logmode, 
they get the SNA sense code of 087D0001, indicating routing was exhausted. 
VTAM also issues messages including IST895I with sense code 80140002 
indicating an invalid APPN COS name. 

The same user can use a another logmode, ALTMOD25, with the 
same 'INTERACT' class of service, and connect just fine across systems, so 
routing and COS are not the issues. I opened a problem with IBM about this. 
While they ponder the issue, I thought I'd bring it to the masses, in hope I 
will 
receive enlightenment.

The differences between the logmode entries are the primary screen sizes and 
the RUSIZES. ALTMOD45 specifies RUSIZES=X'87F8'. ALTMOD25 specifies 
RUSIZES=X'87C7'. Just so no one has to look them up, the values correspond 
as follows: X'87'= 1024, x'C7' = 1536, and X'F8' = 3840, and the first byte is 
the maximum size the SLU can send, and the second byte is the maximum size 
the PLU can send.

So, I changed the RUSIZES on ALTMOD45 to match those on ALTMOD25. That 
works. Huh? That's not what the error codes indicated. 

My assumption is that something in the network routing stuff must limit the 
maximum RU size. Something important like that is surely documented, right? 
Not so. At least not that I found. I checked all of the standard IBM manuals 
for Communications Server, and found nothing indicating any relationship 
between maximum RU size and some other limiting factor. I did find notes 
indicating MTU size can affect performance when messages have to be 
fragmented. I infer from that little nugget of information that the network can 
handle large messages just fine. 

Has anyone else run into this issue? Can anyone point me to the IBM 
documentation that explains this phenomenon? 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Purging STC Waiting on Dataset

[Martin Kline]

>How do I cancel the STC. I've already tried C DTLL / C DTLL,A=nnn  /
>FORCE with the same options. No way to purge?

Try:
 C STARTING,A=asid

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How much will "fit" in a dataset?

[Martin Kline]

>B) the whole stuff is written in Java... This is why I hoped I could do 
>all the needed calculations by myself because calling native stuff 
>(assembler) is "expensive" in Java

Build a table one time, and keep it with the application, avoiding the native 
language call. Using a table lookup, blksize x = max bytes/trk y. Very simple.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Dumb Question - Credit Card Number Scanner

[Martin Kline]

> Okay, this one came to me yesterday.  Somebody asked me if there were
>a way to search all files on a mainframe for credit card number information
>(you know, the 16-digit jobs) for a PCI audit.

Easy. Offer to do the following:

Start with the first byte on the first disk. Convert it and the following 0-n 
bytes to decimal numbers. Put that number in your list of suspiscious numbers. 
Also unpack the same bytes to create a second set of potential numbers. Also 
keep the 16 byte sequence as a suspiscious number. Procede to the next byte 
on the disk. Repeat for the entire disk. Then repeat for all disks. Then repeat 
this process for every tape. You will now have a list of potentially 
suspiscious 
numbers which consumes more space than all of the disks and tapes in your 
shop, probably by a factor of at least 10. Print the list and send it to the 
requester.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Software delivery via internet or tape

[Martin Kline]

>While the SOD doesn't provide any detail on how z/OS will exploit this option, 
>I seem to remember that right  now  z/VM is optionally delivered on DVD and 
>that it can be installed using the z9/z10 internal DVD device...

Looking at my z/VM product DVDs, and thinking, 'Yes, that's right." I installed 
z/VM from the HMC, so why couldn't SMP/E under MVS access the HMC DVD 
drive as well . . . So, just speculating, would 'FROMNETWORK' 
become 'FROMHMC'?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ISPF Counter

[Martin Kline]

>What __might__ be nice. And __would__ prove TSO is not moribund. Would 
>be to have a TSO capability via native TCP/IP. Unfortunately, it appears that 
>the 3270 terminal architecture is so imbedded into TSO that such would be 
>very difficult. Which translates to expensive and time consuming. Better to 
>replace TSO entirely. Which RD/z (or whatever its called now) is trying to do. 
>Unfortunately, compared to TSO and ISPF, RD/z is horribly expensive. Like 
>most "advanced" things on z/OS. z/OS software here>


"Native TCP/IP" may be at the wrong level. TN3270 runs over "Native TCP/IP" 
and provides the protocol for positioning output data, identifying input data, 
standardizing screen sizes in terms of character and line counts, etc. "Native 
TCP/IP" would only provide message traffic, but no formatting. 

Yet, any TSO replacement that expects to support the many existing ISPF 
and other 3270-style data displays would have to still present data in a very 
similar manner. 

Also,I don't believe the issue is so much with the VTAM side of things, either. 
VTAM can support full duplex just fine.

Based on observation, I believe TSO applications are designed so that they 
each expect to have full control of the display. Actually, after thinking about 
it a bit, the line-mode (pre SPF) applications are entirely half-duplex 
functions. 
Following in that design, ISPF does not allow subtasks to run (AFAIR) when 
the application is waiting for input. Thus, having multiple tasks performing 
separate functions and updating different parts of the display image is not 
supported in TSO. 

That is not to say that such functions cannot be supported. 

Many years ago, when I worked at a TCAM shop, and microfiche of much of 
the IBM source code was still available, my employer had a requirement to 
access TSO on multiple systems using a single terminal. TCAM had a 
restriction in its design of TSO that only allowed terminals to use TSO on the 
same system that owned the terminal. I dug into the code and found that all 
of the key routines for TSO had common code, except when they had to work 
specifically with the access method. So, sprinkled through IBM's code were 
tests of a bit in a control block to see if the user was using TCAM or VTAM. 
Since we didn't have VTAM, I stole each of those branch points, and inserted 
my own code. The end result was that I had effectively rewritten TSO as a 
straight TCAM application, which did not have the afore-mentioned limitation 
of which systems it could run on. 

Having been inside that code, I believe an enterprising person or group could, 
with relative ease (perhaps depending on skill and determination) build code 
using the former TCAM intercepts, and redesign some of the TSO functions to 
support whatever design they needed. Digging through long-forgotten 
memory, some of those points to examine are address space create, address 
space termination, plus SVC's 93 and 94. For direct TCPIP use, the application 
would also have to listen on a socket, accept an initial contact and start 
another address space, which would run the main TSO functions for that user 
(LOGON, input, output, etc). 

Now, the other end of the issue is what the user has for their portal. Is it 
using a 3270 emulator? Is it expecting HTML? What about JAVA or something 
else? The display function and the TSO emulator have to be compatible. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: spool offload

[Martin Kline]

>Have a spool offload dataset offload does not recognize format correctly... 
>error on header when using offload,type=receive..

I would create a new small offload (just a single output would suffice) on disk 
to generate a valid header. Then, examine the two files closely to see 
differences. Also compare RECFM, BLKSIZE, etc. If you can tell the 
differences, write a converter program (or use sort, idcams, whatever is 
appropriate) to convert your first offload to the same format as the second.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USSTAB

[Martin Kline]

>You seem to have a sandbox available to you so I would like to suggest some 
>more tests.

>a. Does the VTAM implementation skip order sequences when scanning 
>for "@" characters? Check with HOSTNET preceded by an SF with attribute 
>byte X'7C', "protected", "autoskip" and "nondisplay" - which is going to make 
>it difficult to see! - which tends to being an excuse for not bothering since 
>it's so unlikely.

The VTAM implementation does not skip order sequences for the '@' 
character. These can also cause unintentional problems.

>b. Does the VTAM implementation skip WCC characters when scanning 
>for "@" characters? Check with HOSTNET at the very beginning of the USS 
>message with a X'7C' Write Control Character which means "reset", "80-
>character print line", "start print" - beware in case you have a local printer 
>defined - and "sound alarm".

The VTAM implementation does not skip WCC chartacters either.

>c. Does the VTAM implementation insist on upper case characters when 
>matching "@"-based variables? Check with @hostnet.

Upper and lower case are both matched.

>d. Does the TN3270 implementation skip order sequences when scanning 
>for "&" characters? Check with SYSR1, the volume serial number of the 
>volume used for IPL, preceded by an SF with attribute 
>byte '50',  "unprotected".

The TN3270 implementation does not skip order sequences when scanning for 
ampersands either.

>e. Does the TN3270 implementation skip WCC characters when scanning 
>for "&" characters? Check with SYSR1 at the very beginning of the USS 
>message with a X'50' Write Control Character which means "40-character 
>print line"but, since the "print bit" is not set there no risk of wasting 
>paper!

The TN3270 implementation does not skip WCC characters when scanning for 
ampersands either.

>f. Does the TN3270 implementation insist on upper case characters when 
>matching system symbols? Check with &sysr1.

The TN3270 implementation does recognize only uppercase characters when 
scanning for system symbols.

>g. Just to be sure that this enhancement applies only to USS messages 
>defined using the BUFFER operand and not the TEXT operand, try coding an 
>USS message using the TEXT operand and with &SYSR1 in the text and see 
>what happens. If the system symbol is substituted, try DATE. 

The VTAM implementation replaces the @ variables and not system symbols. 
The TN3270 implementation replaces both.

>Now that you've mentioned that the SCAN|LUNAME suboperand is not 
>required I can't trust any aspect of the TN3270 implementation of variable 
>substitution in USS messages!

No kidding!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: The "Shame" Approach

[Martin Kline]

Nicely worded, Ed. Maybe I'm not imagining things when I believe IBM is more 
interested in closing open problem records than in solving the underlying 
problems. It didn't used to be this way. Having posted this publicly, can I 
assume you don't mind if I use the same response?

>Are you sure you guys work for IBM? You put out a PTF that breaks
>existing specifications, you have a workaround that you don't document
>because it's only a temporary fix, and you're ready to close this PMR
>and move on? At this point, the IBM I know would be adding a ++HOLD DOC
>or ++HOLD ACTION to the PTF or marking the fix as PE until the new fix
>can be delivered.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USSTAB

[Martin Kline]

>You seem to have a sandbox available to you so I would like to suggest some
>more tests.

Yes, but only as time permits - I am working on those tests, but felt you 
should know I haven't dropped the discussion.

>Note that there's not too much point in checking the TN3270 implementation
>with "@"-based variables since the only possibly difficult one is @HOSTNET,
>having only one "@" character.

It's highly unlikely someone would use an SBA ending with x'7C', the '@' 
character, and immediately follow that with the character string, '@PRT', 
resulting in the text '@@PRT' but, 'highly unlikely' is just the type of open 
pit 
someone eventually falls into. It's also 'highly unlikely' someone would turn 
off 
the main power to the data center, but I've seen it happen twice. 

>Which reminds me I got something wrong regarding the MDT in a previous>
>post. Recall that the "&" character when used as an attribute byte implies
>an "unprotected", "input", field. I suggested it was unlikely without the MDT
>bit.

I'm not sure most people know the difference. I believe the ampersand (x'50') 
is representative of the unprotected numeric field without the MDT and with 
normal intensity, not light-pen detectable. It's 'highly unlikely' and even 
slightly absurd to follow this with a non-numeric string like 'SYSNAME'. 
(Defining a numeric input field and filling it with non-numerics).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USSTAB

[Martin Kline]

I appreciate the continued discussion. It's interesting banter.

I have indeed opened an ETR with IBM as a low-priority problem. Progress is 
as expected, slow, though I have gotten the support person to agree there 
is/are issue(s).

I'm not sure how this would be a "requirement." I just want the code to work 
as documented. Untimately, I would prefer the code to work logically and 
precisely under control of the systems programmer. I'm afraid the end result 
will be changed documentation instead. If that's all I get, I plan to continue 
pushing until the documentation clearly outlines the limitations and 
restrictions 
that are currently hidden in the code.

As for Chris Mason's reference to "incompetent" developers, I would not be so 
harsh. I certainly appreciate Chris's support and in-depth knowledge of 
networks, and have often found his comments to be quite valuable. I have 
never worked for IBM, but I have worked with their support for over 30 years. 
Some time ago IBM would not have tolerated the 'sloppy' implementation of  
system symbols in USS tables. ('Sloppy' is my term). These days, though, as 
with quite a few US-based companies, 'competent' means 'good enough'. 
And, 'good enough' means just barely enough to meet the designer's specs, 
ignoring any obvious or discovered shortcomings. It's not the developer's job 
to point out flaws in the design, and oftentimes, doing so only results in the 
developer being reprimanded by "incompetent" managers for going outside the 
scope of the project, even it it could produce a better final product. It's 
also 
not the tester's job to do more than test the ability of the code to perform 
the bare minimum to meet the design, nor to even understand subtle 
characteristics of the environment that could affect the ability of the product 
to work under all conditions. So, not knowing what constraints the developers 
may have had, I hesitate to single them out as incompetent, when it may 
actually be the environment under which they work that values quantity over 
quality and causes them to produce less than stellar results.

Sorry. I read over that paragraph a couple times, and I just don't see how to 
make my point without the soap box. I'll make a note to have my soap box 
burned and the horse buried later. (references to preaching from atop a soap 
box, and to beating a 'dead horse' (overworked subject) to death).

BTW, for everyone (anyone?) who bothered to read this far, how many use a 
custom USS table? Is it just Chris, Patrick, myself and a couple other people 
in 
the world?


Patrick said: 
>The product is "working as designed".  If you want this changed you're going
>to have to submit a Requirement with a very strong business case.  Fixing.
>USS design flaws isn't going to be very high on anybody's list.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: messages IEF285I and IGD104I

[Martin Kline]

The first 3 messages are SMS messages. The third is not an SMS message.

IMHO it's reasonable to assume you should get the same messages for all four 
data sets. Technically, however, I believe SMS is handling the disposition for 
the first three messages, so you get an SMS message for each. Since SMS is 
not handling the disposition for the fourth data set, you get the pre-SMS/non-
SMS message instead. SMS is more-or-less a separate component, so has it's 
own prefix for messages, and does not reuse existing message IDs.

>Well, may be, but all datasets were allocated with disposition = SHARE...
>What does it have to do with SMS?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: messages IEF285I and IGD104I

[Martin Kline]

Is the fifth data set SMS managed like the first four?

>I looked (programmatic) into JESYSMSG file. A ddname defined in JCL (not
>dynamically allocated) concatenates 5 datasets. The first 4 datasets
>reported as retained by msgIGD104I. The last dataset was reported as KEPT 
>by message IEF285I. All datasets are defined in the master  catalog with 
>same devtype. Another concatenating DD is reported as the first dataset by
>IEF285I and the rest by IGD104I.

>Any reason for MVS to report with different messages on datasets that are
>allocated on the same volume and cataloged in the mastcat?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USS misuse

[Martin Kline]

Ulysses, an acquaintance of mine, left USS unexpectedly and is now working 
for the county. Not long after he left, another systems programmer, Ulee, 
needed to update the USS message. He searched all of the primary source 
files at USS for the USS source, but didn't find it. He then tried looking in 
the 
USS user directories and found Ulysses' /u/USS (coincidentially, Ulysses' ID 
was USS), USS source there, called USSSRC. So he was finally able to update 
USS's USS message by changing the USS source in USSSRC at /u/USS.

OK. I admit to not knowing Ulysses personally. However, if you successfully 
followed this message, then you don't need an interpreter to understand what 
USS means. WOuld it be nice if the same interpretation always applied to the 
same acronyms? Sure, but then we'd be left to talking about real problems, 
and that gets boring.

Many of the best systems programmers are successful because they demand 
precision and clarity. Many are successful because they can adapt. Those 
who are precise and clear in their own work and adapt to the environment 
around them have the best of both worlds.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USSTAB

[Martin Kline]

"Strange and wonderful" was a good guess. The code which scans the buffer 
does not check for 3270 orders, and may simply overlay them. Aparable? Since 
the description reads, "The entire string specified by BUFFER is searched, 
using the character @," I suppose this depends on how you want to interpret 
the text.

Another strange behavior is that the system symbols are converted whether 
or not 'SCAN' is specified on the USSMSG macro, but the other '@' variable 
substitutions occured only when SCAN was specified. Also aparable?



John said:
>From the context in which you ask, I'd guess something "strange and
>wonderful" occurs; but I've been too long away from "serious" 3270
>datastream coding to remember anything unusual about SBA addresses
>ending with the values you cite.  Of course, I'm "ass.u.ming" you follow
>the SBAs immediately with SF[E] orders

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Operator Validation before Executing Command

[Martin Kline]

>Windows mentality strikes again.

More likely:

BPXOINIT HAS BEEN SHUT DOWN - REPLY 'OK' TO CONTINUE

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USSTAB

[Martin Kline]

My test showed system symbols were replaced by removing or adding 
characters as necessary. (Because I can't remember exactly how to get 
ampersands to diplay correctly on the list server and I'm too lazy to look it 
up, 
my examples will use pound signs, '#', instead). 

For example '---#SYSNAME---' is displayed as '---SYS1---'. At least on the 
1.9 release I have installed. This does NOT display as '---SYS1---'.

My advice is if you depend on exact positioning for the other characters on 
the screen such as drawing a box around your data, or drawing a pic of a 
dinosaur (like I do), then use SBA orders to position the trailing data 
correctly.

As Chris indicated, the other non-system symbols that can be replaced do 
specify what happens with alignment, spaces, numerics, etc. The issue is with 
the system symbols, because the names of the variables may be either longer 
or shorter than the values that get substituted.

Bonus question:

If your USS message contains SBA orders, and the address happens to end in 
X'7C', such as such as X'11C17C' for row 2 column 45 on an 80-character wide 
screen, and the following characters happen to match one of the allowed 
keywords, what happens? Likewise, what happens when the SBA happens to 
end in X'50'?


Chris said:
>I too would be interested in testing mainly because the manner in which the
>MVS system symbol is inserted totally absent from the description, a
>deficiency on a par with the botched way in which this new function has
>been described.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USSTAB

[Martin Kline]

Chris said:
>This question of which version of the USS table also occurred to me after my 
>last post. I would assume the one used by the Communications Server IP 
>component TN3270 server program in both Ron's case and Juergen's. 
>However, when Communications Server development change the USS table 
>processing, I am sure they will be sure to cover both the VTAM use and the 
>TN3270 server use.

That sound like a reasonable assumption, however reason, logic and intuition 
may not apply. At least in 1.9, the TN3270 and VTAM processing of USS 
tables appear to differ. Maybe the communications developer teams don't 
 communicate with each other. o.O

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USSTAB

[Martin Kline]

Juergen asked:
>I've looked through the IP-Reference (1.8 - SC31-8776-10) and did not find 
>any entry that you can use system symbols in USSMSG. There are some 
>varables starting with @ but no system-symbols. Is it a function in 1.9 or 
>1.10?

I am using the 1.9 manual. SC31-8776-13 Section 2.10.4.3. quote:
LUNAME|SCAN 
Specifies that the character strings listed in Table 30 are replaced
with the appropriate values in the position in the message where the
character string occurred. The entire string specified by BUFFER is 
searched, using the character @. System symbolics are also replaced 
with their appropriate value. . . .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USSTAB

[Martin Kline]

I said:
>VTAM and TCPIP handle the screens differently if the manuals can be 
>trusted. The two manuals are SC31-8776 z/OS Communications Server IP 
>Configuration Reference, and z/OS Communications Server SNA Resource 
>Definition Reference.

Check the manuals for you installed release of z/OS. The availability of system 
symbols in USSTAB processing appears to have changed between z/OS 1.7 
and z/OS 1.9.  The manuals I used above are both for z/OS 1.9. The 1.7 
versions do not refer to using system symbols in the USSTAB. Both versions, 
however, allow the use of certain symbolics for dynamic substitution. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USSTAB

[Martin Kline]

VTAM and TCPIP handle the screens differently if the manuals can be trusted. 
The two manuals are SC31-8776 z/OS Communications Server IP Configuration 
Reference, and z/OS Communications Server SNA Resource Definition 
Reference. 

Both manuals describe the USSMSG macro. Both specify that if you want to 
dynamically substitute certain values such as LUNAME, HOSTNET, SENSE, 
SSCP name, etc, then y6ou have to code the USSMSG macro with the SCAN 
operand. Then, in the area defined by BUF1, you can code any of the 
supported symbols. Because some of the symbols, such as sense code and RU 
name, can only be supplied when the message is being displayed, VTAM and 
TCPIP must be scanning the message for symbols and replacing them at that 
time.

MSG10  USSMSG  MSG=10,BUFFER=(BUF1,SCAN)

BUF1DC   AL2(length of buffer)
  . . .
   DC   C'---WELCOME-@@SSCPNM'
  . . .

The IP reference, however, also indicates that you can use system symbols, 
whereas the SNA reference does not. SO, if this USS table is being loaded by 
TCPIP/TN3270, then you may be able to use system symbols. But, if the table 
is loaded by VTAM, then you may not.

The IP reference also makes a vague reference to how the assembler handles 
the ampersand symbol. It indicates that you must code double ampersands in 
your 'DC' instruction in order to get a single ampersand in the assembled code. 
That is correct. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USSTAB

[Martin Kline]

That should specify two ampersands and the character string 'SYSPARM' 
without my quotes and without spaces.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: USSTAB

[Martin Kline]

>Anyone have a copy/example of using &sysparm in the USSTAB for VTAM 
>logon screen,, to place system-id on screen. I know there is something once 
>on the cbt tape but I do not have access to it..

No sample, but code "BUFFER=(addr,SCAN)" on the USSMSG macro, and code 
within the buffer wherever you want "&&SYSPARM". The extra '&' gets 
removed by the assembler.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Offload work to ziip

[Martin Kline]

>I'm not saying it is right.  But this is the Pandora's box that Neon
>seems to be opening.  In reality, a large company would most likely be
>much more subtle, and add additional capacity as ZxxP engines instead of
>GP's, and stay under the radar so to speak.

Interesting discussion. A few bit-wise systems programmers have likely already 
found similar methods for utilizing ZiiP and ZaaP engines, and Neon may have 
found the legal loopholes or IBM support to profit from it. Good for them. It's 
probably not for publication, but I imagine similar systems programmers could 
just as easily enable all of the physical engines (licensed or not) to run at 
full 
speed. After all, if you're willing to skirt the license by utilizing ZiiPs and 
ZaaPs 
for unintended use, then why not go all the way using the argument of, "My 
organization bought the machine, and they should have the right to use all of 
it any way they want."

BTW, I have not personally attempted either approach to maximize CPU 
availability, although I probably have the ability to do so, and believe there 
are others who can and are willing to do the same.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Throttling FTP

[Martin Kline]

>>I would go with setting up Quality of Service (QoS) mechanisms on your 
>>CISCO router, if FTP traffic is impacting your interactive workload. 

>We went with three levels of service, in order of priority:
>1. VOIP
>2. INTERNET
>3. FTP

>It's a good thing!

Interesting! I wonder if our network team is up to the challenge? Surely they 
are, aren't they? I mean they're the Network Team afterall. Then again, they 
didn't come up with this option. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Throttling FTP

[Martin Kline]

John said:

>I think what you want is QoS (Quality of Service). I got a headache trying to 
>read:

>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B381/2.7

Thanks, John. I appreciate the reference. That pain medication industry owes 
you one. ;)

>From what I've read so far, it appears that this only applies to the TCPIP 
stack on which the policy is managed. Since z/OS is not the bottleneck, my 
guess is that the effect of setting up the appropriate QoS stuff on z/OS will 
be of no benefit to the affected CIP router. In fact, to make matters worse, 
the CIP router is connected to two z/OS systems, one of which has the 
onlines, and the other the batch work. 

In any case, I'll read on to see if there's any light at the end of the manual.
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Throttling FTP

[Martin Kline]

We have some large batch FTP processes that were recently identified as the 
cause of major network slowdowns for online processing. More specifically, 
one of our CIP routers becomes a bottleneck when batch FTP jobs start 
flooding it.

We are working on a process to ensure that particular FTP batch processes 
are run on a system that will not affect the problem router.

IFAIR, VTAM has/had pacing options that could help manage just this sort of 
situation. Does FTP or TCPIP have a similar capability? I found nothing in the 
FTP configuration about throttling or pacing. Maybe someone else has run into 
a similar situation. How did or would you deal with this situation?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CLIST cc 828?

[Martin Kline]

>I got a cc 828 on the following clist code, and the %USERPROC executed 
>even though the condition seems to be false.

Works ok for me, replacing the execution of USERPROC with a WRITE 
command. 

Sorry to ask the obvious, but 1) are you certain this is the failing line? 2) 
Is 
there a continuation preceding this line? 3) Could the error be in USERPROC 
instead? (Try running USERPROC directly.)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: BDAM vs VSAM

[Martin Kline]

OP:

>In to days Z/OS environment is BDAM faster than VSAM. I understand that 
>IBM does not recommend the use of BDAM, however for those installations 
>that are heavy Assembler and continue to use BDAM has there been any 
>bench marks for the use of BDAM ?

>The I/OS Subsystem and Access methods have all improved since there 
>inception. So I'm wondering why some mainframe software providers continue 
>to choose BDAM over VSAM.

Multiple questions. 1) Yes, BDAM is definitely faster than VSAM for some 
applications. VSAM is faster than BDAM for some other applications. 

2) Most likely benchmarks have been run, however I have no evidence on 
hand.

3) Choosing BDAM over VSAM or visa versa can have multiple factors. For 
critical log files, I would definitely prefer BDAM. I want to know the data is 
written to disk before continuing, and not be left to wondering of VSAM got 
around to chaining some buffers yet. Can I force VSAM to write those buffers? 
Maybe, but it takes a little extra effort I wouldn't have to do with BDAM. Is 
it 
just random keyed records I want to read and write? Then VSAM might be the 
choice. 

I think the understanding that IBM does not recommend the use of BDAM may 
be correct - literally. Unless some document states, "IBM recommends you use 
BDAM for . . .," then that statement is true. They may not recommend against 
it either - or do they?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: BDAM vs VSAM

[Martin Kline]

>BDAM does not buffer. You incur a synchronous wait while the bock of data 
>is transferred from or to the device. This wait can be inferred by the average 
>device response time. 

It's up to the BDAM application to manage buffers itself. If it's applicable, 
get 
some storage, keep some data blocks in memory, and avoid some I/O. And, 
no, you do not incur a synchronous wait unless you choose to do so. That 
much is the same for VSAM. If the application has something else it can do 
after issuing the request to start the I/O, it should do so whether it is using 
BDAM or VSAM (or VTAM or TCPIP, or DB/2 . . .). 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: BDAM vs VSAM

[Martin Kline]

>BDAM performance is easy to predict/measure. Simply look that the average 
>device response times and add a little for CPU overhead. Compare to a well 
>tuned VSAM that approaches zero as the buffer hits and lookaside hits 
>approach 100%.

Apples and Turnips. You're comparing pure I/O against software logic for 
buffer management. Add similar logic to your BDAM program to manage it's 
own buffers and rerun the comparison.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: QSAM - Blocking logic defect for VB file?

[Martin Kline]

Johnny said:

>One of our customers had a problem in their production batch jobs. One
>COBOL program writes variable length records to a VB PS data set and after
>smoothly running for ten years the program begun to generate VB files with
>invalid RDWs as reported by DFSORT which is used to copy the files.  We are
>at z/OS 1.9.

Did you recently update the run time libraries? Was the program recompiled 1) 
before the problem started or 2) before the problem resolved itself?

What do the FD and data descriptions specify? When the program calculates 
the length before writing, how does it communicate that information to QSAM?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Temporary Data Set Duplicate Name Bahavior

[Martin Kline]

Thanks to John for the reference. That pretty much answered my question.

Richard said:
>I am  curious to see what you read in the JCL reference.

I was looking at 4.1.1.2 in the JCL User's Guide where it says, "if the same 
temporary data set name appears more than once in a job, the system might 
create duplicate data set names. This would be a JCL error. . ." Which is 
where I stopped reading. The rest of the sentence reads, "Unless the data set 
is passed from one job step to another." It does not go on to further explain 
what happens when the duplicate name is passed.

Unfortunately this did not explain the behavior as well as the section on 
passed data sets. 

Also unfortunately, JCLCHECK gave a misleading message, "CAY6218W TEMP 
DSN "&T1" WAS SPECIFIED AS NEW TWICE. IT WILL BE REUSED". 

Ah well. Lesson learned. JCL changed. All water under the bridge. 

Thanks for the responses.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Temporary Data Set Duplicate Name Bahavior

[Martin Kline]

We recently had a job using duplicate temporary data set names and got 
some really unexpected results. I didn't find this behavior documented 
anywhere, thus the post.

First, to validate the results, I created a simple four-step job. All four 
steps 
use IEBGENER. Step 1 creates a temporary data set named &&T1 with DISP=
(NEW,PASS). Step 2 copies &&T1 using DISP=(OLD,PASS) to SYSOUT. Step 3 
repeats step 1, also with data set name &&T1 and DISP=(NEW,PASS), but 
with different data going to the SYSUT2. Step 4 copies &&T1 to SYSOUT. 

All steps ran with return code zero. The result is that steps 2 and 4 copied 
the same &&T1 to SYSOUT both times. The second &&T1 data set was 
apparently simply discarded. 

The generated data set name for &&T1 was the same for all steps. 

The JCL reference indicates I should have gotten a duplicate data set name 
JCL error. But I did not. 

Since &&T1 went to VIO in the first test, I ran it again with the file 
going to 
DASD. Allocations for the two &&T1 files were SMS managed, went to 
different disk volumes, and had identical names. Again, the first &&T1 file 
was 
the one copied to SYSOUT both times.

For validation, I changed steps 3 and 4 to use data set name &&T2. Steps 2 
and 4 provided different SYSOUT data as expected.

Sure, there are multiple ways to avoid this issue, such as using different temp 
names or using DISP=(OLD,DELETE) in steps 2 and 4. That's not the issue. 
That's already taken care of.

The issue is that the behavior is unexpected and contrary to the 
documentation. Has anyone run into this before and found the behavior 
documented somewhere?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Share Spool

[Martin Kline]

>ok--following is what I intended but guess I'm still missing it...
>intent is being able to use N9 to still route sysout from opther lpar's 
>besides N1 so do I need or can NODE(9) have same name as NODE(1) ?
>system SYSA 
>
>LOGON(1) APPLID=SYSA

>MASDEF
> OWNMEMB=SYSA9  >>> smfid
>SHARED=CHECK, 
>XCFGRPNM=SYSA

>MEMBER(1) NAME=SYSA9
>MEMBER(2) NAME=SYSD 

>NJEDEF
>OWNNODE=1

>NODE(1)  NAME=SYSA

>NODE(9)  NAME=SYSD>> to join in shared spool

>APPL(SYSD) NODE=9  >>


First, all the members sharing the same spool and checkpoint are in the same 
MAS system. That's "shared spool". That collection of JES2 instances sharing 
the MAS is a single JES2 node. Therefore, if SYSA and SYSD are in the same 
MAS, then they are the same node. That node has one node number. Only 
one. It's either node 1 or node 9, but not both.

If you have other LPARs not sharing the MAS that want to communicate with 
the MAS and currently refer to it by the node number, 'N9" in this case, then 
make the entire MAS node number 9. Both SYSA and SYSD being part of the 
shared spool, will both be node 9. Using your member statements, SYSA would 
be member 1 of node 9, and SYSD would be member 2 of node 9. 

With that setup, when you route output from other nodes to N9, the output is 
placed into NODE 9's shared spool, and can be accessed by both SYSA and 
SYSD. 

Externally, other NJE systems see the MAS as a single node. Whether they 
connect to SYSA or to SYSD is determined by the APPLID they connect to.  
For example, if SYSX connects to APPLID SYSA, it is connected to member 1 
of NODE 9. If SYSX instead connects to APPLID SYSD, it is still connected to 
NODE 9, but to member 2 instead. Whether external systems connect via 
SYSA or SYSD makes no difference when the output arrives at node 9 
because it's shared spool - shared between members SYSA and SYSD.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Share Spool

[Martin Kline]

>NODE(nn)  since it was originally setup non-shared...and the NAME= not 
>matching anything other than the APPL and LOGON for that system..
>would it have any use ??
>Since NODE(1)>> OWNNODE is now both the same ??

Yes. Node(1) tells JES2 which what symbolic name you want for the MAS. 

It's been a long time since I dealt with connecting JES2 networks, but as I 
remember it, the name for your node should be relatively unique if you ever 
expect to connect multiple networks together - more important when those 
networks belong to other organizations than when they belong to a single 
conglomerate. You can avoid a lot of confusion that way.

My personal recommendation for node names is to use the company name or 
stock id along with a numeric or location reference. Your chances of running 
into duplicate network names are greatly reduced. 



For example, suppose you choose 'SYSA' as your node name and VTAM 
APPLID. Then suppose CompanyX wants to connect to your network to allow 
JES2 to send reports to them directly, but CompanyX also selected 'SYSA' as 
their node name and APPLID. One of you would have to change. Not so bad 
with single-node networks.

Worse, suppose you already connected to dozens of other JES2 networks 
owned by other companies, and your node name and applid were 'NEWYORK'. 
Then you run into CompanyZ, which also has multiple connected JES2 systems 
with many other companies, one of which also elected to use the node 
name 'NEWYORK'. 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Share Spool

[Martin Kline]

>The MEMBER (nn) is just a number or the node number relationship?

Member and node are two separate numbers. A JES2 node can have multiple 
members - thus shared spool. Each member has a different number. The 
MEMBER statement specifies which number slot is used by each system 
sharing the spool. 

>MASDEF   DORMANCY=(070,600),
> HOLD=60, 
> LOCKOUT=1000, 
> OWNMEMB=SYSA, 
> SHARED=CHECK, 
> XCFGRPNM=SYSX,CF, 
> SYNCTOL=240 
>MEMBER(1) NAME=SYSA>>> 
>MEMBER(2) NAME=SYSD >>> can this be or should it be the same 
>name as I have in old setup?>> sing SMFid as for node number--kept same 
> NJEDEF  OWNNODE=1 >> same on both def's in jes

In your case Both systems should specify OWNNODE=1. On the MASDEF 
statement for SYSA, you should have OWNMEMB=SYSA, and on the MASDEF 
for SYSD you should have OWNMEMB=SYSD. Each system in the MAS 
identifies its own name to the MAS in this way. (If not specified, then 
OWNMEMB defaults to the SMF ID).

The SPOOLDEF and CKPTDEF statements for both systems should also match.

Each member of the MAS has to have a different member number. So, both 
members should have the same pair of MEMBER statements in their 
parameters.  The MEMBER(1) NAME=SYSA and MEMBER(2) NAME=SYSD 
identify which member number is assigned to each of the member names. 

JES2 can take a lot of defaults - like using SMF ID for the member name, but I 
prefer to specify the MAS parameters explicitly, so whenever I have a 
question about how it works, I'm not doing research about how each 
parameter might have defaulted.

>But still have old NODE(nn) defined for old system when not shared spool 
>..>> guess that can be eliminated ?

That depends on whether or not NODE(nn) still exists, and, if so, whether or 
not you want to your MAS communicate with it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Share Spool

[Martin Kline]

Ron asked:

>understand the NJEDEF.. OWNNODE s/b same on both JES2parms 
>But in the case of the NODE(nn)>> are they not still defined as seperate 
>NODEnumber and NAME being the name of that system ?

I'm not certain what you are asking, but I'll give it a shot. The entire MAS is 
one JES2 node. NJEDEF specifies the OWNNODE number for the MAS. NODE
(nn) specifies the name of the MAS. Each member of the MAS should have the 
same name and node number for the MAS. 

Each member of the MAS is defined by a MEMBER(nn) NAME=. So, each 
member of the MAS has its own member number and name. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Changing a SYSOUT writer

[Martin Kline]

George said:

> Given these JCL statements:

>//OUT01A OUTPUT CLASS=R,WRITER=W1,FORMS=F000 
>//OUT01 DD SYSOUT=(,),  OUTPUT=(*,OUT01A) 
>//OUT02A OUTPUT CLASS=R,WRITER=W1,FORMS=F999 
>//OUT02 DD SYSOUT=(,),  OUTPUT=(*,OUT02A) 

>What I am trying to do is to dynamically change the WRITER used for the
>OUT01 DD from W1 to W2 within an assembler program. 
>   My program gets control before the OUT01 file has been opened. I
>was thinking that I could get to the PDDB control block before the JOE
>is built for the file, and change it there prior to opening it, but I
>haven't been able to get to the PDDB. Does anyone know if this will work
>and how I can get to the PDDB?
>   This is not a JES exit.

It sounds like a lot of unnecessary work. I assume your data or environment 
determines which writer you want. If your program is simply chosing between 
two writers, then use two separate sysout DDs. Write to the one with the 
correct writer name.

On the other hand, if your program needs more flexibilty, such as to change 
the writer based on an unknown number of possibilities, then it would be 
simpler to use the documented interface for dynamic allocation. I believe you 
can find information about that in the authorized assembler programmer 
guide/reference.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: VSAM BLSR

[Martin Kline]

>I would expect different SHRPOOLS to be cumulative, would probably bet big
>money on it, even though I don't really know such from  documentation much
>less a dump. But what about multiple BLSR requests for the same SHRPOOL.
>Does it sum them up and BLDVRP for the sum, just the largest, or what?

The first ACB opened causes the BLDVRP to be done using the parameters for 
that DD only. You should receive message CSR024I indicating SHRPOOL 1 is 
being reused when the second ACB is opened.

If H99NMODF is opened first, the buffer space is (4096*7972)+(8092*272) = 
over 33 meg. If H99NPFLG is opened first, the buffer space is (4096*4070)+
(8192*532) = over 20 meg. 

>No the concern is not performance, the concern is memory. We are a little
>tight on what we allow in REGION around here and 48M in a SHRPOOL at least
>50% of which seems to be TOTAL waste doesn't get it. The step sucks up 
>189M above the line and crashes.  The JCL is a bit more reasonable on the 4 
>or 5 files in the default SHRPOOL.

I agree that the oversized buffers are wasting space. If the BUFSI and BUFSD 
are defaulted, then the space is 'minimized'. However, if the two files had 
different CI sizes, then your specification would not work if the one having 
the 
smaller CISIZE were opened first. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Group Cap/MSU's question

[Martin Kline]

FWIW, I prefer option 1. 

In effect, option 2 is similar to having two separate machines, one with a 
capacity of 40, and another with a capacity of 20. Neither LPAR can utilize 
unused capacity from the other. So, when LPAR B is practically idle, LPAR A 
still cannot use more than 40.

Option 1 allows LPAR A to utilize up to 83% of all CPU, and LPAR B up to 50%. 
This more effectively utilizes resources. The weights will keep the balance 
right when both LPARS have the demand to use more than their 2/3 or 1/3. 


>I am interested to find out which of the 2 options below is better and why?

>OPTION 1:
> LPAR A   DEFCAP=50
> LPAR B   DEFCAP=30
> GROUP CAP = 60

>  OR

>OPTION 2:
> LPAR A   DEFCAP=40
> LPAR B   DEFCAP=20
> GROUP CAP = 120

>Assume that in both cases LPARS have access to all the CP's(2 CP CEC) and 
>their weights are set at 65% and 35%.We are running on a  z9 EC machine 
>with z/OS 1.9 in WLM goal mode. Also assume that both LPARS 4 hour rolling 
>average will hit the caps and IMS,DB2,MQ run on both LPARS.

>My view is that in both cases above the MAX MSU's charged will be 60MSU's. 
>If this is correct I am trying to understand which of the above options is 
>better overall CPU utilization (Peak and non-peak times).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA's Error codes

[Martin Kline]

>Thanks for staying with this.

>> If by "CS IP PROFILE" you mean the TCPIP parameteres pointed to by the
>>PROFILE DD statement in our TCPIP proc ...

>Indeed I do. They are the statements described in Chapter 2, "TCP/IP profile
>(PROFILE.TCPIP) and configuration statements" in the z/OS Configuration 
>Server (CS) IP Configuration Reference manual.

>You would appear to qualify for this test since you don't have DYNAMICXCF
>defined as a parameter of your IPCONFIG statement.

>Now take a look at the messages in the log of the CS IP address space, 
>possibly under the name TCPIP, and see whether in the first 20 or so 
>messages there is one which states 

>EZZ0331I NO HOME ADDRESS ASSIGNED TO LINK IUTSAMEH

This message does not appear.

>just as Stuart Willis reported in his original post.

>However, also looking in the PROFILE data set, perhaps you can say whether 
>or not you have coded a pair of DEVICE and LINK statements of the form

>DEVICE IUTSAMEH MPCPTP
>LINK linkname MPCPTP IUTSAMEH

Found:
DEVICE  IUTSAMEH MPCPTP   
LINKEELINK MPCPTP IUTSAMEH

Also found:
   10.0.208.10EELINK

>If the answer is that you have defined such a pair of statements and you 
>have also coded an entry in the HOME list assigning an IP address to
>linkname, then you don't qualify for this test!

I don't qualify. Wait! What was I qualifying for? Was this a qualifying race or 
certification thing or something? Weren't you just asking for an example? 
Based on your original request, that's what I gave. Sorry you had something 
else in mind.

>If you have not defined such a pair of statements and you have no entry in
>the HOME list with the link name EZASAMEMVS, then you do qualify for this
>test.

Now I'm confused. First, where did 'EZASAMEMVS' come from? Second, If I 
have the DEVICE, LINK and HOME entry I don't qualify. If I have none of 
those, I do qualify. What if I have the DEVICE and LINK but not the HOME 
entry? That's the situation on one of our systems. 

Parameters:
DEVICE  IUTSAMEH MPCPTP 
LINKEELINK MPCPTP IUTSAMEH  

Message: 
EZZ0331I NO HOME ADDRESS ASSIGNED TO LINK EELINK 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA's Error codes

[Martin Kline]

>Go and have a look in your CS IP PROFILE data set for DYNAMICXCF.

If by "CS IP PROFILE" you mean the TCPIP parameteres pointed to by the 
PROFILE DD statement in our TCPIP proc, DYNAMICXCF is not coded there 
either. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA's Error codes

[Martin Kline]

>If there is someone still reading this who has experience with CS IP
> *without* DYNAMICXCF specified who can state whether or not IUTSAMEH
>is defined automatically, I for one would like to hear about it - perhaps
>Stuart himself.

DYNAMICXCF does not appear anywhere in our VTAMLST, but a display of 
ID=IUTSAMEH shows:

IST075I NAME = IUTSAMEH, TYPE = TRLE  
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV   
IST087I TYPE = LEASED , CONTROL = MPC , HPDT = YES
IST1954I TRL MAJOR NODE = ISTTRL  
IST1715I MPCLEVEL = HPDT   MPCUSAGE = SHARE   
IST1717I ULPID = TCPIP
IST1500I STATE TRACE = OFF
IST314I END   

This is under z/os 1.9.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Question

[Martin Kline]

>We are able to FTP to a tape drive on our current system, however when we
>FTP to a tape drive on the Z/OS 1.9 system  we get the following
>Error (error code 0218 info code  S99ERSN 0FD6)

The 0218 error code indicates the user may not have MOUNT authority. Check 
the TSO/E customization manual and search for MOUNT or TSOAUTH. Your 
security admin may have to ake a change.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Question about how to use BSAM to access very large files

[Martin Kline]

A little math. x'CD13' = 52499. Since this is relative to zero, make that 
52500. 
Track 52500 is cylinder 3500, a coincidentally very round number. Could it be 
that you have 3500 cylinders on the first volume of a multi-volume file?

If I recall my BSAM days, you can't simply point to data on the second or 
subsequent volume of a multi-volume data set. I always used another DCB for 
each volume. 

I don't believe BSAM prevents you from processing the data sequentially 
across multiple volumes, which might explain the phenomenon you are seeing. 


>The problem I am having is that I cannot POINT to a track beyond 00CD1308
>and successfully read that track (I get a 42 condition in the ECB).  An
>interesting side note is that when I do a POINT at 00CD1308, I can
>successfully read sequentially through the rest of the file (I know I am
>reading good records by the time stamps in each record).  The TTTR 
addresses
>returned by FIND commands after each READ appear to be wrapping, though,
>never exceeding 00B8 (there are 8 blocks per track).  It looks like it
>is not handling large addresses in either the POINT or FIND.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: GDG Question

[Martin Kline]

I prefer to order GDGs with odd generations in LIFO order followed by the even 
generations in FIFO order - except on the second Tuesday of the month, 
when I want to read the data backwards in random file sequence. Why won't 
IBM listen to me?

You can't satisfy everyone. I suspect it was a performance choice made many 
years ago. For whatever reason, it is what it is. Deal with it or get over it.

Nevertheless, this is a perfect situation for a little bit of subsystem code. 
Let 
the subsystem search the catalog and concatenate the files in whatever 
sequence you like.


>The thing that's always bugged me about GDG files is they way they are
>selected starting with the highest gen # first down to the lowest if you
>specify the GDG-base name on a DD.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

GDGs, Long Dataset Names, Generated DSNs, etc.

[Martin Kline]

I've been following this extensive discussion of GDG's and the side notes 
related to generating unique dataset names, long dataset names, GDG limits 
and other limitations. 

These are all just characteristics of the underlying architecture, which is 
unlikely to change. What you do with that architecture is only limited by your 
imagination.

IBM provided a really nice facility for doing whatever you want with 
these 'limitations'. If you want some added features, write a subsystem. 
There's really not much to it. I'm surprised some enterprising person, group or 
organization hasn't done so already.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3270 session disconnects

[Martin Kline]

You may be timed out by the application to which you signon. Telnet/tn3270 
may have a timeout value. TSO has a timeout value. TPX and Teleview and 
other session monitors have timeout values. CICS may have a timeout value. 
The Telnet parameters may also be set to disconnect when you end the 
application session (or it is timed out and ends). 

So, my first question would be, "What is one of the applications?"

2nd, what are the telnet options?


>I (and many other users) are presently experiencing what appears to be 
>random disconnects of our 3270 terminal emulator sessions.  The disconnects 
>seem to only occur after random periods of little or no activity.  Our 
>terminal 
>emulator software is predominately Rumba (Wall Data).  I have installed and 
>tested with both Mocha and Vista3270 with the same results.  I have been 
>banging my head against a wall while trying to figure this one out, with 
>little 
>success.  Any advice, suggestions, diagnostic recommendations, etc are 
>certainly welcome.

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CLIST/REXX Philosophy

[Martin Kline]

"Should?" They 'should' be whatever best fits your environment. 

Having worked with both, I prefer the VB/255 format, which works well with 
my 43X132 display. Generally, I don't extend data beyond 124 columns, as 
that's what edit normally displays. That's 72% longer displayed data than the 
80-column displays allow, allowing for nicely formatted code most of the time.

-Original Message-
From: Rick Fochtman 
Sent: Wednesday, December 17, 2008 9:15 AM
To: IBM-MAIN@bama.ua.edu
Subject: CLIST/REXX Philosophy

I'm probably going to start a firestorm here, but it's for an internal
argument here where I'm consulting.

Should REXX/CLIST datasets be RECFM=FB,LRECL=80, or should they be
RECFM=VB,LRECL=255? Why?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Uncatalog usercatalog CATINDEX

[Martin Kline]

>When I do a list cat on the catalog it only shows me the aliases, it does not 
>show me the catalog attributes, which is what I was looking for and believe 
>that the CATINDEX is where the catalog attribute is found. 

My guess is that you are listing the master catalog entry for the user catalog. 
Try something like:

LISTCAT ENTRIES(ucatname) ALL CATALOG(ucatname)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Display Active Users panel (DA)

[Martin Kline]

>RMF III also shows the storage in number of frames (the STORF display).
>But at least it used K and not T. 

So, RMF III uses the ambiguous 'K' and fails to put a definition in the help. 
'K' 
could mean 1000 and it could mean 1024. If it's 1024, then without using a 
calculator and in less than 2 seconds, how many frames if 635K? 

In what way is that better than using 'T', when 'T' clearly means 1000? How 
many frames is 635T?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Display Active Users panel (DA)

[Martin Kline]

Real storage is allocated in 4k frames. 22T means 22,000 frames. Why bother 
converting to bytes? That's no better than converting to words or half-words 
or bits. So, 22T is meaningful. 22 thousand FRAMES.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Capturing LOAD/DELETE SVCs for a Certain Program

[Martin Kline]

>   However, the GTF trace is capturing all SVC 8 and 9 events for the 
address 
space.

 >  What am I doing wrong? Can I not use a combination of GTF and SLIP to 
specify my criteria???

Your GTF options are telling GTF to collect all SVC 8/9 for the job as well as 
all 
slip records. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.10 and Data Areas

[Martin Kline]

Rick Fochtman:
>>As Bob Shannon noted, the initial z/OS 1.10 bookshelf did not have the 
>>data areas books. IBM developers (and perhaps others) complained and 
>>apparently now they do. There is no indication that this will 
>>necessarily continue in subsequent releases.

>>I would still appreciate your comments regarding "PDF-only" even if it 
>>applies only to potential subsequent releases.
--

>Peter, I much prefer the BookManager form for all manuals. The search 
>engine is far better, even if it does often provide "hits" that aren't 
>really relevant to what I need.

Bookmanager = fast, simple and elegant. PDF = slow, cumbersome and pretty. 
As for those 'hits that aren't really relevant,' it's much better than the PDF 
sequential search. How many times do I have to look at the contents, 
summary of changes and intro in every PDF? I also have to wait while Adobe is 
started and each PDF is loaded. Since I'm usually on TSO in the first place, 
that's where I prefer to find my manuals.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/VM and Mirrored DASD owned by z/OS

[Martin Kline]

> You might want to re-post on the IBMVM listserv.

Done, but I was under the impression that this was a 'mainframe' discussion 
list, whereas the IBMVM list is strictly VM, and that since my issue stems from 
a conflict between z/OS and z/VM that this list would be more appropriate.

My apologies for wasting everyone's time.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/VM and Mirrored DASD owned by z/OS

[Martin Kline]

Thanks for the responses. Marking the devices 'notsupported' should fix the 
immediate problem.

Is anyone successfully using PPRC devices in z/VM? 

The documentation indicates PPRC is fully supported by VM and its guests, but 
if the support is that every PPRC device must be marked 'notsupported', I'd 
have to say that's a contradiction. Similarly, there is nothing in the 
documentation about having to do anything special when sharing DASD - such 
as marking the devices 'notsupported' - before starting z/VM. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html