Re: CF Structures - ALLOWAUTOALT

[Vernooij, CP - SPLXM]

Sorry, after reading again, I see this is no good anwer. I now see that
my answer is your question. Reallocate effectuates policy changes, but
we have ALLOWAUTOALT(yes). However, from the doc, I read that this
effects automatic alters to the structure size when it is allocated and
does not influence REALLOCATE. 

AFAIK Reallocate should always honour the pending policy changes.
Chapter 4.6.3.2 REALLOCATE Process: 
You can use the SETXCF START,REALLOCATE operator command to do the
following: 
Dot 5: Clean up pending CFRM policy changes...

Kees.

"Vernooij, CP - SPLXM"  wrote in message
news:<3310ac9d797ec94db8d89ccabdea47a702ce3...@kl1221tc.cs.ad.klmcorp.ne
t>...
> It will honour the CFRM policy, so you should update the policy to
what
> the application thinks is appropriate and then do the Reallocate.
> 
> Kees.
> 
> 
> "Richards, Robert B."  wrote in message
>
news:<2d14e7856646224aacdda13ab1d355570c8b92e...@wdcv7exvs2.opm.gov>...
> > Oops!
> > 
> > I meant *WITHOUT* ALLOWAUTOALT.
> > 
> > Bob
> > 
> > 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Richards, Robert B.
> > Sent: Monday, September 13, 2010 10:54 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: CF Structures - ALLOWAUTOALT
> > 
> > Did that (SETXCF START,REALLOCATE) and it would *not* effect the
> change with ALLOWAUTOALT, hence my question.
> > 
> > Bob
> > 
> > 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Vernooij, CP - SPLXM
> > Sent: Monday, September 13, 2010 10:47 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: CF Structures - ALLOWAUTOALT
> > 
> > "Richards, Robert B."  wrote in message
> >
>
news:<2d14e7856646224aacdda13ab1d355570c8b92e...@wdcv7exvs2.opm.gov>...
> > > Is anyone using this and if so, have you seen any downside?
> > >
> > > I have a structure out there with policy change pending and it is
> > always allocated. User wants larger size and we are taking the
default
> > of NO for all structures.
> > >
> > > Please advise.
> > >
> > > Bob
> > >
> > 
> > You can use the SETXCF command to initiate a rebuild for the
structure
> > to effectuate the pending policy change.
> > 
> > Kees.
> > 
> > For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only.
If
> you are not the addressee, you are notified that no part of the e-mail
> or any attachment may be disclosed, copied or distributed, and that
any
> other action related to this e-mail or attachment is strictly
> prohibited, and may be unlawful. If you have received this e-mail by
> error, please notify the sender immediately by return e-mail, and
delete
> this message.
> > 
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or
> its employees shall not be liable for the incorrect or incomplete
> transmission of this e-mail or any attachments, nor responsible for
any
> delay in receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> Dutch Airlines) is registered in Amstelveen, The Netherlands, with
> registered number 33014286
> > 
> > 
> >
--
> > 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
> > 
> >
--
> > 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
> > 
> >
--
> > 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
> 
> For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee only. If
you are not the addressee, you are notified that no part of the e-mail
or any attachment may be disclosed, copied or distributed, and that any
other action related to this e-mail or attachment is strictly
prohibited, and may be unlawful. If you have received this e-mail by
error, please notify the sender immediately by return e-mail, and delete
this message. 
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
its employees shall not be liable for the incorrect or incomplete

Re: z/OS non-sms dasd allocation algorithm ?

[Ron Hawkins]

John and Steve,

Back around 1995 SMS and non-SMS allocation was documented in a very
detailed informational APAR. I no longer have a copy of it.

My recollection is that the eligible device list for was built in least busy
LCU and volume order, where busy was based on a reasonably short SRM measure
of connect time. I don't recall non-SMS or SMS Primary EDL being sorted by
device delay. Something in the deep recesses of my memory says that the
volume order within LCU was changed to number of datasets open at some
stage, but that may be a senior moment in progress.

So initially we have the EDL in least busy LCU, and then least busy volume
order, but allocation will then demote any volume that has already been
allocated to a dataset in this job step to avoid "clustering" of allocation
on a single, low activity device. This is why you don't see all you SORTWKnn
datasets on one volume, and another dim dark memory is prodding me to say
that the DFSORT guys asked for this enhancement.

You also have to consider that temporary datasets will select volumes
mounted as PUBLIC over those mounted as STORAGE. Accidently mounting one
volume as PUBLIC in your work pool with everything else mounted as STORAGE
is a good way to see a single volume become grossly overloaded with all the
TEMP dataset allocations.

CA-ASTEX does a really good job of getting it's fingers into allocation by
removing poor performing candidates from the EDL. The product documentation
may have a good write up on what happens without ASTEX. Or Chris Craddock
can run down the hall and get one of the developers to respond...

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> John H Kington
> Sent: Monday, September 13, 2010 10:55 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] z/OS non-sms dasd allocation algorithm ?
> 
> Steve,
> 
> >Does anyone know how a dasd volume is selected for a new non-sms dataset
> >allocation when using the UNIT parm?  Is it  just the first volume in the
> UNIT
> >group that satisfies the space request or is some other algorithm used?
> >Anyone know if this is documented anywhere (IBM manual)?  z/OS 1.9
> >
> You are asking for information on non-specific, non-sms dasd dataset
> allocation.
> I don't know anyplace where everything is fully documented but you can use
> the above to search the archives.
> 
> Assuming you are allocating a permanent dasd dataset and you have no third
> party product that is directing/controlling allocation, the system will
build
> a
> candidate list of volumes associated with the unit that are mounted
storage.
> The list is then sorted by device delay (iosqueue time, pending time and
> disconnect time) from lowest to highest. Allocation then occurs on the
> first volume in the sorted list that has sufficient space in five extents
or
> less.
> 
> Regards,
> John
> 
> NOTICE:  The information contained in this electronic mail transmission is
> intended by Convergys Corporation for the use of the named individual or
> entity to which it is directed and may contain information that is
privileged
> or otherwise confidential.  If you have received this electronic mail
> transmission in error, please delete it from your system without copying
or
> forwarding it, and notify the sender of the error by reply email or by
> telephone (collect), so that the sender's address records can be
corrected.
> 
> --
> 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

--
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: CF Structures - ALLOWAUTOALT

[Vernooij, CP - SPLXM]

It will honour the CFRM policy, so you should update the policy to what
the application thinks is appropriate and then do the Reallocate.

Kees.


"Richards, Robert B."  wrote in message
news:<2d14e7856646224aacdda13ab1d355570c8b92e...@wdcv7exvs2.opm.gov>...
> Oops!
> 
> I meant *WITHOUT* ALLOWAUTOALT.
> 
> Bob
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Richards, Robert B.
> Sent: Monday, September 13, 2010 10:54 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CF Structures - ALLOWAUTOALT
> 
> Did that (SETXCF START,REALLOCATE) and it would *not* effect the
change with ALLOWAUTOALT, hence my question.
> 
> Bob
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Vernooij, CP - SPLXM
> Sent: Monday, September 13, 2010 10:47 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CF Structures - ALLOWAUTOALT
> 
> "Richards, Robert B."  wrote in message
>
news:<2d14e7856646224aacdda13ab1d355570c8b92e...@wdcv7exvs2.opm.gov>...
> > Is anyone using this and if so, have you seen any downside?
> >
> > I have a structure out there with policy change pending and it is
> always allocated. User wants larger size and we are taking the default
> of NO for all structures.
> >
> > Please advise.
> >
> > Bob
> >
> 
> You can use the SETXCF command to initiate a rebuild for the structure
> to effectuate the pending policy change.
> 
> Kees.
> 
> For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee only. If
you are not the addressee, you are notified that no part of the e-mail
or any attachment may be disclosed, copied or distributed, and that any
other action related to this e-mail or attachment is strictly
prohibited, and may be unlawful. If you have received this e-mail by
error, please notify the sender immediately by return e-mail, and delete
this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
its employees shall not be liable for the incorrect or incomplete
transmission of this e-mail or any attachments, nor responsible for any
delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
> 
> 
> --
> 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
> 
> --
> 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
> 
> --
> 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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
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: Jobclas Protection - IEFUJI

[Ed Gould]

--- On Fri, 9/10/10, Mark Zelden  wrote:

From: Mark Zelden 
Subject: Re: Jobclas Protection - IEFUJI
To: IBM-MAIN@bama.ua.edu
Date: Friday, September 10, 2010, 2:19 PM

On Fri, 10 Sep 2010 14:02:14 -0500, Dave Kopischke
 wrote:


>
>I think a RACF hook in the exit would be a better approach. I'd also be
>interested in seeing a code example of this...
>

Someone already posted a sample IEFUJI.  It looks similar to mine
but mine used an installation defined class instead of FACILITY and the
resource name was  "JOBCLASS.x".   My JES2 exit 6 used the same
check. 

>Our OPS/MVS approach is also manual, so it's not optimal. Someone has to
>maintain the table and change it as things change. Employees, JOB Classes,
>etc. It's just a lot more flexible and quicker to adjust than a JES exit.
>


Mark:
I do like your way better than the way I did mine. My main problem with doing 
it via security call is that (yes I know) I have seen various people dodge 
though holes this way (security call) its a complicated story but it was done a 
few times. The other thing I implemented (and is no longer needed) was to 
comment out a stepcat. I understand why IBM came up with the stepcat/jobcat 
card long long ago and far far away but it complicated everybodies life by its 
existance. It took me 2 years of nagging the standards committee to let me 
implement the exit and it really did save me problem determination time that it 
was a constant sore spot with me. I think the biggest offenders were 
consultants as once I caught an employee using it a call to their boss pretty 
well stopped it. Consultants had this "I know better" attitude that after I 
implemented the exit I was getting calls that the stepcat was broken for 2-3 
months. It made my day to call thier boss to
 remind them that step/jobcat were not allowed.
*BUT* for quite sometime *I* needed it as not all of the issue of not needing 
the stepcat had been fixed by IBM. Even then once in a great while I needed it 
when working with catalogs in emergency situations. I held by breath when IBM 
dropped them and hoped and preyed I did not run into any of those MUST have 
situations.
Ed





--
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

current used main-memory( realmemory, central memory)

[Leopold Strauss]

 Hi all,

I would need a snapshot about the amount of current used main-memory.

With RMF-monitor-II-snapshot this value is not provided.

Are there any systemcalls or controlblock-chains to be looked for to get 
this value ?


I would appreciate any hints.

Thanks in advance and BR

Leo Strauss


On 13.09.2010 19:23, Gerhard Postpischil wrote:

On 9/13/2010 10:35 AM, Bill Fairchild wrote:

step, testing a program that does only a SYNCH macro to see
if the system can survive.


The problem was fixed in MVS with the introduction of LSQA and the E04 
abend code.


But the SYNCH macro is overkill, a bare SVC 12 suffices. 
On a 4 meg 360/65 it took almost an hour to crash MVT.

Gerhard Postpischil
Bradford, VT

--
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




--
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: System Dump - Long non-dispatchable

[George Kozakos]

>Since we upgraded to z/OS 1.11, we have encountered a couple of system
>dumps that have set the system non-dispatchable during global data
>capture for 15 seconds!  This long delay caused an application outage
>because the application could not tolerate that long of wait.
>
>The two dumps causing the long wait were unrelated (i.e. different
>products/different abends).  We have had other system dumps where the
>global data capture only took about 1 second.
>
>IBM is looking at one of the dumps where the system was set
>non-dispatchable for 15 seconds, but I was wondering if anyone has
>encountered this?

Hi Mike,
You will be notified via the PMR but for the information of the
rest of the list the problem is described by OA34275.

It affects systems at HBB7760 and higher that specify QUIESCE=YES.

George Kozakos
z/OS Software Service, Level 2 Supervisor

--
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: CA ESP Workload Automation

[amit]

I second Neil on his comments.
i have had the pleasurable experience of working/migrating and supporting
ESP for quite a while now and found it to be absolutely Delightful.
The features and controls have been quite streamlined for different Support
groups which can be monitored/audited as per will and easy use...not to out
mention, the GUIs specially helps the Prod control guys with minimum
training as its quite elaborate and easy use.
Also to appreciate its robust Cross platform integration under one umbrella
management!

Cheers,
Amit

On Tue, Sep 14, 2010 at 3:20 AM, Neil Duffee  wrote:

> ESP499I ESP RELEASE  5.5 SP2 INITIALIZED,
>
> Approaching 2 decades of use from when it was a CyberMation product.
>  **VERY** pleased with the product tho' we're concerned with how it might
> morph/sunset under CA's ownership.
>
> Can't talk about other products since the only comparison was done at
> initial purchase.  However, at that time, the person to become the major
> user - our Production Control guy - spent 2-4 months of investigation.  I
> recall him specifically mentioning zeke, zak, & CA-7(?) among others that
> were deemed lesser than ESP.  [then]
>
> In fact, it would take major effort to replace it in our environment since
> it's become ubiquitous.  Besides the initial user, Operations, Systems, DBAs
> all run their tasks with it and there are also a number of users that
> support their applications with it.  I have an application designed to span
> more than a week which stops the running job at a specific time of day and
> re-subs it on the next day.  Tho' it's not used anymore, I had another
> multi-day application that allowed vault tapes time to return to the data
> centre for amalgamation and later return.  I even have an application that
> will cycle - daily - a group of back-end services (singly threaded) such
> that only half are stopped at any point in time.
>
> I understand that it now provides functionality (we don't have/use it) to
> extend the automation to other hosts (*nix, Linux, win, AS/400) using z/OS
> as the central management hub.
> -->  signature = 6 lines follows <--
> Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada
> telephone:1 613 562 5800 x4585 fax:1 613 562 5161
> mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee
> "How *do* you plan for something like that?" Guardian Bob, Reboot
> "For every action, there is an equal and opposite criticism."
> "Systems Programming: Guilty, until proven innocent" John Norgauer 2004
>
>
> > -Original Message-
> > From: gsg [mailto:gsg...@yah..com]
> > Sent: September 10, 2010 17:37
> > Subject: CA ESP Workload Automation
> >
> > Does anyone use a CA job scheduler product called ESP
> > Workload Automation?
> >
> > PROS/CONS compared to other job schedulers?
>
> --
> 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
>

--
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: Another brain-dead quoted PROC parm question

[Charles Mills]

I'm sorry, I don't understand the relevance to my question. How does this
address the problem of passing quotes in quoted strings in a PROC parameter
without quadrupling them?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Scott Ford
Sent: Monday, September 13, 2010 5:42 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Another brain-dead quoted PROC parm question

This is a  of what i have done and it works:

//SET1
Howard:

This is a  of what i have done and it works:

//SET1   SET   ODSN=PROD.JCLLIB
//SET4A  SET   OBLOCK=3120

//STEP1  EXEC  PGM=IEFBR14
//*---*
//*  IEFBR14 ALLOC OUTPUT LIBRARIES
//*---*
//INDD1  DD    DSN=&ODSN,
//   DCB=(DSORG=PO,RECFM=&ORECFM,LRECL=&OLRECL,
//   BLKSIZE=&OBLOCK),UNIT=SYSDA,SPACE=(TRK,(300,100,60)),
//   DISP=(NEW,CATLG)

--
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: Another brain-dead quoted PROC parm question

[Scott Ford]

This is a  of what i have done and it works:

//SET1
Howard:

This is a  of what i have done and it works:

//SET1   SET   ODSN=PROD.JCLLIB
//SET4A  SET   OBLOCK=3120

//STEP1  EXEC  PGM=IEFBR14
//*---*
//*  IEFBR14 ALLOC OUTPUT LIBRARIES
//*---*
//INDD1  DD    DSN=&ODSN,
//   DCB=(DSORG=PO,RECFM=&ORECFM,LRECL=&OLRECL,
//   BLKSIZE=&OBLOCK),UNIT=SYSDA,SPACE=(TRK,(300,100,60)),
//   DISP=(NEW,CATLG)

Regards,
 
Scott J Ford
 





From: Howard Brazee 
To: IBM-MAIN@bama.ua.edu
Sent: Mon, September 13, 2010 4:39:41 PM
Subject: Re: Another brain-dead quoted PROC parm question

On 13 Sep 2010 12:59:13 -0700, charl...@mcn.org (Charles Mills) wrote:

>If I code it as PARM='&STRING', then if the user wants to pass in a string
>with quotes in it, he needs quadruple quotes, e.g.
>
>//MYSTEP EXEC BAR,STRING='The value is 3.14'
>
>which I find fairly ridiculous and non-intuitive and error-prone. Is there
>some trick to being able to have a PROC parm that is quoted but does not
>need quadruple quotes? I tried the trick setting &Q to  and using that
>instead of a literal quote and also a null parameter &X to fool JCL but
>couldn't get those to work either.

I agree.  My first question here, is whether you can change the
program so that instead of using a parm, you use an input card.

--
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





--
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: Another brain-dead quoted PROC parm question

[Charles Mills]

In reverse order:

> //MYSTEP EXEC BAR,PARM.STEP1='The value is ''3.14'''

That's a good idea. That's about the best I had come up with so far. It will
be a single-step proc, so all I actually need is PARM=. It's a little odd --
it does not show up in a Substitution JCL message so it looks like it went
into the bit bucket -- but it's a workable idea.

> //MYSTEP EXEC BAR,STRING='The value is \3.14\'

That's a possibility. I might use " as the pseudo-quote character. I've got
two cases:

- parm is going to go through my parser. For that case I don't even need a
translate; I can just accept a " as equivalent to a '. For that case the "
works great:
STRING='DSN("BLAH.BLAH(MEM)")'

- parm is an arbitrary string. That case is a little weird:
STRING='Life isnt fair'
STRING='Life isn\t fair'
STRING='Life isn"t fair'

I'm not sure which is the least weird.

I think I like the PARM= solution the best. The least weird of all.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Schwarz, Barry A
Sent: Monday, September 13, 2010 3:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Another brain-dead quoted PROC parm question

Modify FOO to translate the parm by replacing a designated character (such
as \) with a quote.  You can then code the proc invocation as
 //MYSTEP EXEC BAR,STRING='The value is \3.14\'
and code the jobstep as
 //STEP1 EXEC  PGM=FOO,PARM='&STRING'

Your translate table is simply
 TBL  DC256AL1(*-TBL)
  ORG   TBL+C'\'
  DCCL1' '
  ORG
and the translation is performed with a single TR.

Alternately, instead of coding the parameter in the proc invocation using
STRING, use
 //MYSTEP EXEC BAR,PARM.STEP1='The value is ''3.14'''
and only use the "normal" double quotes instead of quadruple ones.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Charles Mills
Sent: Monday, September 13, 2010 12:58 PM
To: IBM-MAIN@bama.ua.edu
Subject: Another brain-dead quoted PROC parm question

I've got a program FOO that requires a string with embedded blanks as a
parm, e.g.
//STEP1EXEC  PGM=FOO,PARM='Hello World'

I'd like to be able to set up a proc BAR that would take a parm STRING= and
pass it to FOO as the PARM=, e.g.

//BAR   PROC  STRING='the string'
//STEP1 EXEC  PGM=FOO,PARM=&STRING

If I do it that way, then it fails for lack of quotes around &STRING.

If I code it as PARM='&STRING', then if the user wants to pass in a string
with quotes in it, he needs quadruple quotes, e.g.

//MYSTEP EXEC BAR,STRING='The value is 3.14'

which I find fairly ridiculous and non-intuitive and error-prone. Is there
some trick to being able to have a PROC parm that is quoted but does not
need quadruple quotes? I tried the trick setting &Q to  and using that
instead of a literal quote and also a null parameter &X to fool JCL but
couldn't get those to work 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

--
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: Issuing WTOR SVC In Multitask Environment

[John McKown]

On Mon, 2010-09-13 at 17:04 -0400, Shmuel Metz (Seymour J.) wrote:
> In <4c8d729d.1070...@mentor-services.com>, on 09/12/2010
>at 08:38 PM, Mike Myers  said:
> 
> >If you only want a single TCB to dominate a CPU, you may want to go
> >back  to OS/360 (Sequential Scheduling System
> 
> Single Sequential Scheduler.
>  

Is that like OS/360 PCP? I've heard of that, but hadn't heard of Single
Sequential Scheduler before.

I still wonder what the OP really wants and 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: Does anyone combine OMEGAMON and OMEGAVIEW in the same CSI?

[Paul Gilmartin]

On Mon, 13 Sep 2010 16:48:09 -0400, Shmuel Metz (Seymour J.) wrote:
>
> 1. A PTF should only apply to one FMID.
>
Not exactly.  From:

#<<3.7.1.3 "SMP/E V3R5.0 for z/OS V1R12.0 Commands"
 ___
 

 
3.7.1.3 Applicability checking  
 

 
1. Each SYSMOD must contain at least one ++VER statement whose SREL 
 
   value matches one of the SREL values for that target zone and whose  
 
   FMID value (if present) names a function SYSMOD that has been (or is 
 
   being) applied.
   ...
   If a SYSMOD is found containing multiple applicable ++VER
 
   statements, SMP/E is unable to apply that SYSMOD, because SMP/E  
 
   cannot determine which ++VER statement to use.   

So a PTF can contain multiple ++VER statements, each identifying
a different FMID.  It's not clear whether the APPLY FORFMID
parameter restricts this.  And I don't see the syntax whereby
a PTF for one FMID can REQ itself for a different FMID.

But "(if present)" indicates that the FMID on the ++VER is
optional, so perhaps your PTF should omit FMID, in which
case it would just float aimlessly in the TARGET and DLIB
zones, not belonging to any FMID.

Remember that DDDEFS belong to the zone, not to the FMID,
so you can't have identical DDNAMES in the same zone identify
different data sets for different FMIDs.

Perhaps Kurt Q. will clarify.

-- gil

--
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: GTF trace help / SLIP trace capture

[John McKown]

On Mon, 2010-09-13 at 16:52 -0400, Shmuel Metz (Seymour J.) wrote:
> In ,
> on 09/13/2010
>at 07:47 AM, "McKown, John"  said:
> 
> >Has anyone here ever run GTF to capture TRACE events from a SLIP
> >trap?
> 
> Sure. You display USR records with IPCS. You can take your input from
> the GTF output dataset or from a dump containing the GTF records.
>  

Hum, I used the GTF command in IPCS and it worked. But I was wondering
how (TRACE=SLIP in GTF parameters) to collect the SLIP information,
which another person pointed me to the book. I'm having another bad day.
They are becoming endemic.

You answered the question. But not the need. Much as I do at 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: GTF trace help / SLIP trace capture

[Binyamin Dissen]

On Mon, 13 Sep 2010 07:47:04 -0500 "McKown, John"
 wrote:

:>I can't find the stupid book on how to set the GTF options. Has anyone here 
ever run GTF to capture TRACE events from a SLIP trap? The SLIP is from IBM on 
a DFSORT problem and looks like:

TRACE=SLIP

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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: Another brain-dead quoted PROC parm question

[Schwarz, Barry A]

Modify FOO to translate the parm by replacing a designated character (such as 
\) with a quote.  You can then code the proc invocation as
 //MYSTEP EXEC BAR,STRING='The value is \3.14\'
and code the jobstep as
 //STEP1 EXEC  PGM=FOO,PARM='&STRING'

Your translate table is simply
 TBL  DC256AL1(*-TBL)
  ORG   TBL+C'\'
  DCCL1' '
  ORG
and the translation is performed with a single TR.

Alternately, instead of coding the parameter in the proc invocation using 
STRING, use
 //MYSTEP EXEC BAR,PARM.STEP1='The value is ''3.14'''
and only use the "normal" double quotes instead of quadruple ones.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Charles Mills
Sent: Monday, September 13, 2010 12:58 PM
To: IBM-MAIN@bama.ua.edu
Subject: Another brain-dead quoted PROC parm question

I've got a program FOO that requires a string with embedded blanks as a
parm, e.g.
//STEP1EXEC  PGM=FOO,PARM='Hello World'

I'd like to be able to set up a proc BAR that would take a parm STRING= and
pass it to FOO as the PARM=, e.g.

//BAR   PROC  STRING='the string'
//STEP1 EXEC  PGM=FOO,PARM=&STRING

If I do it that way, then it fails for lack of quotes around &STRING.

If I code it as PARM='&STRING', then if the user wants to pass in a string
with quotes in it, he needs quadruple quotes, e.g.

//MYSTEP EXEC BAR,STRING='The value is 3.14'

which I find fairly ridiculous and non-intuitive and error-prone. Is there
some trick to being able to have a PROC parm that is quoted but does not
need quadruple quotes? I tried the trick setting &Q to  and using that
instead of a literal quote and also a null parameter &X to fool JCL but
couldn't get those to work 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: Issuing WTOR SVC In Multitask Environment

[Binyamin Dissen]

On Sun, 12 Sep 2010 17:05:47 -0400 "Robert A. Rosenberg" 
wrote:

:>At 01:42 -0400 on 09/12/10, michealbutz wrote about Re: Issuing WTOR 
:>SVC In Multitask Environment:

:>>WTOR   'WAIT AND DON'T GIVE CONTROL TO ANOTHER TASK.',REPLY,1,RESPECB
:>>So instead of doing a WAIT ECB=RESPECB AFTER THE WTOR
:>>HARDLOOP DS   0H
:>> TM   RESBECB,X'40'
:>> BNO  HARDLOOP

:>The TM can be done in a processing loop with the BNO being replaced 
:>with a BO to the routine to be run when the Reply is made. If not 
:>posted yet, you go on and do other work. I think the EVENTS Macro can 
:>also be used to create request to go to that routine when the reply 
:>is made (it schedules an exit to be fired off when the ECB is POSTed).

Did not see the original post, but even this hard loop will not prevent other
tasks in the address space from running. This task will eventually reach its
time interval and will lose control, and there are always other CPU's.

The easiest way to stop the other tasks is to do an ENQ with SMC=STEP. Then
you can issue a normal WAIT.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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: CA ESP Workload Automation

[Neil Duffee]

ESP499I ESP RELEASE  5.5 SP2 INITIALIZED,

Approaching 2 decades of use from when it was a CyberMation product.  **VERY** 
pleased with the product tho' we're concerned with how it might morph/sunset 
under CA's ownership.

Can't talk about other products since the only comparison was done at initial 
purchase.  However, at that time, the person to become the major user - our 
Production Control guy - spent 2-4 months of investigation.  I recall him 
specifically mentioning zeke, zak, & CA-7(?) among others that were deemed 
lesser than ESP.  [then]

In fact, it would take major effort to replace it in our environment since it's 
become ubiquitous.  Besides the initial user, Operations, Systems, DBAs all run 
their tasks with it and there are also a number of users that support their 
applications with it.  I have an application designed to span more than a week 
which stops the running job at a specific time of day and re-subs it on the 
next day.  Tho' it's not used anymore, I had another multi-day application that 
allowed vault tapes time to return to the data centre for amalgamation and 
later return.  I even have an application that will cycle - daily - a group of 
back-end services (singly threaded) such that only half are stopped at any 
point in time.  

I understand that it now provides functionality (we don't have/use it) to 
extend the automation to other hosts (*nix, Linux, win, AS/400) using z/OS as 
the central management hub.
-->  signature = 6 lines follows <--
Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585 fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee
"How *do* you plan for something like that?" Guardian Bob, Reboot
"For every action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent" John Norgauer 2004
 

> -Original Message-
> From: gsg [mailto:gsg...@yah..com] 
> Sent: September 10, 2010 17:37
> Subject: CA ESP Workload Automation
> 
> Does anyone use a CA job scheduler product called ESP 
> Workload Automation?
> 
> PROS/CONS compared to other job schedulers?

--
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: Issuing WTOR SVC In Multitask Environment

[Shmuel Metz (Seymour J.)]

In <000d01cb52ad$d9e3b5b0$8dab21...@net>, on 09/12/2010
   at 03:08 PM, michealbutz  said:

>Its only for testing

Do you not share the test LPAR with outher users?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: Issuing WTOR SVC In Multitask Environment

[Shmuel Metz (Seymour J.)]

In <4c8d729d.1070...@mentor-services.com>, on 09/12/2010
   at 08:38 PM, Mike Myers  said:

>If you only want a single TCB to dominate a CPU, you may want to go
>back  to OS/360 (Sequential Scheduling System

Single Sequential Scheduler.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: GTF trace help / SLIP trace capture

[Shmuel Metz (Seymour J.)]

In ,
on 09/13/2010
   at 07:47 AM, "McKown, John"  said:

>Has anyone here ever run GTF to capture TRACE events from a SLIP
>trap?

Sure. You display USR records with IPCS. You can take your input from
the GTF output dataset or from a dump containing the GTF records.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: Does anyone combine OMEGAMON and OMEGAVIEW in the same CSI?

[Shmuel Metz (Seymour J.)]

In , on
09/13/2010
   at 03:30 PM, George Henke  said:

>Just looking for some thoughts on this from SMP/E guru's

 1. A PTF should only apply to one FMID.

 2. Element names should be globally unique.

 3. If a PTF requires service in a different FMID, it should use
an ifreq.

 4. It's normal for related FMID's to share the same target zone.
In fact, it's unusual for them to not share.

What's in the MCS for the PTF in question?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: Another brain-dead quoted PROC parm question

[Charles Mills]

> whether you can change the program

Without boring you with details I have a number of possibilities open to me.
Each has certain shortcomings. If I could overcome THIS shortcoming of THIS
approach it would be my most desirable option IMHO.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Howard Brazee
Sent: Monday, September 13, 2010 1:40 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Another brain-dead quoted PROC parm question

On 13 Sep 2010 12:59:13 -0700, charl...@mcn.org (Charles Mills) wrote:

>If I code it as PARM='&STRING', then if the user wants to pass in a string
>with quotes in it, he needs quadruple quotes, e.g.
>
>//MYSTEP EXEC BAR,STRING='The value is 3.14'
>
>which I find fairly ridiculous and non-intuitive and error-prone. Is there
>some trick to being able to have a PROC parm that is quoted but does not
>need quadruple quotes? I tried the trick setting &Q to  and using that
>instead of a literal quote and also a null parameter &X to fool JCL but
>couldn't get those to work either.

I agree.   My first question here, is whether you can change the
program so that instead of using a parm, you use an input card.

--
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: Oracle mainframe gateways

[Neil Duffee]

Frank : don't know better details, since we don't use that functionality, but 
one of the supposed abilities of the "Oracle Transparent Gateway for DB2" 
(OTGDB2) was as a 2-way conduit ie. not only Oracle to DB2 (our usage) but DB2 
to Oracle.  You might investigate the IMS gateway to verify that It *doesn't* 
offer outbound queries as well.  

-->  signature = 6 lines follows <--
Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585 fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee
"How *do* you plan for something like that?" Guardian Bob, Reboot
"For every action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent" John Norgauer 2004
 

> -Original Message-
> From: Frank Swarbrick [mailto:fran...swar...@efir...com] 
> Sent: September 1, 2010 17:33
> Subject: Oracle mainframe gateways
> 
> [snip] Doesn't solve my issue of getting from z/OS to Oracle, [snip]

--
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: O/T IBM to Ship World's Fastest Computer Chip

[Scott Rowe]

I see no details (interesting or otherwise) in that article that were not 
previously known.  In fact, there are more errors than details.

>>> Ed Gould  9/10/2010 12:44 AM >>>
Here are some more interesting details to this new 
processor:http://www.extremetech.com/article2/0,2845,2368264,00.aspIBM 
Describes Fastest Microprocessor Ever


CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


--
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: CA OPS/MVS phone home

[Kirk Talman]

We have/had a home grown version of that.  It included a M$W server 
accessed via MQ and using VRU.  Server and its software were not replaced 
for cost reasons :-)

Now using just SMTP sending to SMS and/or email.

IBM Mainframe Discussion List  wrote on 09/10/2010 
12:25:04 PM:

> From: Jack Kelly 
> To: IBM-MAIN@bama.ua.edu
> Date: 09/10/2010 12:38 PM
> Subject: CA OPS/MVS phone home
> Sent by: IBM Mainframe Discussion List 

> Does OPS have the ability to call a phone number and send a message to 
> someone? Or does another product, eg NetView?
> I assume that any of them can send a email but I hate assumption?
 
> TIA
> Jack



-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

--
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: SFTP Ported Tools

[Starr, Alan]

Hi Ken,

I can address some of your questions. I'm doing this from memory because I 
don't have the time to look everything up, so some names may be a bit off. I 
apologize in advance for any errors. We use sftp and keys for transfers between 
Linux/Unix and the mainframe. For mainframe-to-mainframe, we use FTP-S 
(certificates). I'll confine myself to discussing sftp (via an ssh server) with 
keys.

If the ssh client is in the mainframe (e.g. Ported Tools), the Unix/Linux 
(server) must have a host key in its /etc/ssh directory and the userid 
associated with the (mainframe) client must have a user key in its 
/u/userid/.ssh directory. Both keys can be generated with ssh-keygen.

When the mainframe client attempts to log in to a ssh sever, the ensuing 
handshake first establishes the server's credentials. The (Linux/Unix) server 
identifies itself to the client by sending it a message that incorporates the 
key saved in its /etc/ssh. The client looks in its /etc/ssh/ssh_known_hosts and 
then in the client user's /u/userid/.ssh/known_hosts for the sending server's 
key. If it does not find it, the client issues a message indicating that the 
server is unknown and asking if you wish to proceed. If you respond 
affirmatively, the server's "host" key is added to your 
/u/userid/.ssh/known_hosts file and the handshake proceeds. 

The server and client play footsies to determine which security mechanism they 
both support (e.g. certificates or Kerberos or key or password). Key gets 
precedence over password, so the client sends two things to the server

1) A userid that is defined at the server which the client wishes to log in with
2) An "identifying token" that was encrypted using the client's PRIVATE key
   (i.e. saved in the client user's /u/userid/.ssh directory).

The server attempts to decrypt the "identifying token" using the PUBLIC key 
that was previously saved in the server user's /u/userid/.ssh/authorized_keys 
file. If the "identifying token" can be decrypted, logon continues as if a 
password had been specified. Otherwise, the server requests the password for 
the specified userid.



In a nutshell:

To facilitate any user of a mainframe image to log into a Linux/Unix (server) 
ssh, copy the server's public key file from its /etc/ssh directory to the 
mainframe's /etc/ssh/ssh_known_hosts  Mainframe users will thereafter not be 
bothered by the "unverifiable server" message.

To enable a mainframe user to log into a Linux/Unix (server) ssh without 
specifying a password, one of the records in the /u/userid/.ssh/authorized_keys 
file on the server side must be the same as the *.pub file in the mainframe 
user's /u/userid/.ssh



You can permit many mainframe users to access the same Linux/Unix (server) user 
by copying the key files from mainframe /u/userid1/.ssh to /u/userid2/.ssh As 
long as the server /u/userid/.ssh directory (i.e. for the userid on the server 
side) contains the mainframe user's key in its authorized_keys file, it's 
happy. It doesn't matter a whit what the mainframe userid is. It also doesn't 
matter which user generated the key. It's the location of keys rather than 
userids themselves that actually matters. 

Note that there is an annoyance factor involved in copying keys from one user's 
directory to another: the plaintext userid appended to the end of the key 
record will be out of sync with the userid in $HOME.


I hope that the above makes some sort of sense and addresses some of your 
questions. 

Regards,
Alan 






-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Ken Porowski
Sent: Monday, September 13, 2010 12:18
To: IBM-MAIN@bama.ua.edu
Subject: SFTP Ported Tools

Just trying to get this working but the doc leaves much to be desired.

Note, our use of SFTP will probably be limited to internal use (Mainframe to a 
common SFTP server within my network) so I'm not too worried about duplication 
or sharing keys across multiple users.

Q1. Anyone know o a Redbook or presentation that takes you step by step?
I have the OpenSSH Users Guide from IBM.

Q2. Do I need to generate user keys or can I just use the host key?

Q3. For a user key does the user generating the key have to be the user to use 
the key?  (i.e. can I (UID(0) or non (0)) generate all keys for all users and 
just move them to the right files?

Q4. Can I copy the keys and change the human readable (i.e. the
hostname) portion at will? I won't touch the actual key.

Q5. I assume all sites I connect to will need my host (and user) keys, Can I 
just email the .pub files or do I need to extract them into a special format 
(ssh-keygen -e)

Q6. Do I need to use pass phrases or can I leave them null.

I have been RTFM but it is unclear on the above items and seems overly 
complicated.

Thanks all

Ken Porowski
VP Mainframe Administration
CIT Group



--
For IBM-MAIN subscribe / signoff / 

Re: Another brain-dead quoted PROC parm question

[Howard Brazee]

On 13 Sep 2010 12:59:13 -0700, charl...@mcn.org (Charles Mills) wrote:

>If I code it as PARM='&STRING', then if the user wants to pass in a string
>with quotes in it, he needs quadruple quotes, e.g.
>
>//MYSTEP EXEC BAR,STRING='The value is 3.14'
>
>which I find fairly ridiculous and non-intuitive and error-prone. Is there
>some trick to being able to have a PROC parm that is quoted but does not
>need quadruple quotes? I tried the trick setting &Q to  and using that
>instead of a literal quote and also a null parameter &X to fool JCL but
>couldn't get those to work either.

I agree.   My first question here, is whether you can change the
program so that instead of using a parm, you use an input card.

--
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

Does anyone combine OMEGAMON and OMEGAVIEW in the same CSI?

[George Henke]

Currently we have OMEGAMON and OMEGAVIEW in separate CSI's.

Recently we applied a PTF to resolve an OC4 to OMEGAMON but the same PTF
also needed to be applied to OMEGAVIEW and was not.

There are those who think had they been in the same CSI this problem would
not have occurred.

If they are separate FMID's and even if in the same CSI and sharing the same
GLOBAL ZONE and PTS, and maybe even the same TARGET ZONE, I question whether
the PTF would have co-req'ed across FMID's.

But I guess that all depends on the UCL in the PTF.

Just looking for some thoughts on this from SMP/E guru's and/or OMEGAMON
users with a similar experience.

Does anyone out there combine OMEGAMON and OMEGAVIEW in the same CSI?

On Mon, Sep 13, 2010 at 1:55 PM, George Henke  wrote:

>
>
> --
> George Henke
> (C) 845 401 5614
>



-- 
George Henke
(C) 845 401 5614

--
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

New instruction mnemonics

[Abe F. Kornelis]

Hello all,

(Cross-posted to HLASM-list)

The new instruction mnemonics for the z196 
include a number floating point instructions

that already existed. An A has been appended
to their mnemonics. Why is that?
That is because a rounding mode could not
be specified; it was always taken from the
FP control register. Now these same instructions
allow specification of an explicit rounding mode.
Some examples:
ADTR --> ADTRA
AXTR --> AXTRA
CDFBR --> CDFBRA 
CDGBR --> CDGBRA

etc.

At first I thought the A was for Additional rounding spec.
Unfortunately, there are also a number of really new 
floating point operations. These all have the same

facility - a rounding mode can be explicitly specified,
or defaulted to the rounding mode in the FP control reg.
Only - these mnemonics do not end in an A.
For example:
CDFTR (but not CDFTRA)

So I've decided that the is probably meant to
indicate Alternative - as opposed to the pre-existing
version of the same instruction without the explicit
rounding mode.

I find this whole setup rather illogical. To code these
instructions correctly I need to memorize whether
the instuction I'm using is pre-z196 or not.
If it is, I can use the old mnemonic with default
rounding mode or the new Alternative one with 
explicit rounding mode.

But if it is not, I can only use the mnemonic without
the additional final A, yet am obliged to code the
required rounding mode explicitly. Use zero for
using current value of FP control register.
So much for compatability.

I think IBM should have carried existing logic
forward: use mnemonics without A to generate
code with default masks having zero values,
and supply additional mnemonics with appended A
to enable explicit specification of rounding mode.

Any thoughts?

Kind regards,
Abe Kornelis.
=

--
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

Another brain-dead quoted PROC parm question

[Charles Mills]

I've got a program FOO that requires a string with embedded blanks as a
parm, e.g.
//STEP1EXEC  PGM=FOO,PARM='Hello World'

I'd like to be able to set up a proc BAR that would take a parm STRING= and
pass it to FOO as the PARM=, e.g.

//BAR   PROC  STRING='the string'
//STEP1 EXEC  PGM=FOO,PARM=&STRING

If I do it that way, then it fails for lack of quotes around &STRING.

If I code it as PARM='&STRING', then if the user wants to pass in a string
with quotes in it, he needs quadruple quotes, e.g.

//MYSTEP EXEC BAR,STRING='The value is 3.14'

which I find fairly ridiculous and non-intuitive and error-prone. Is there
some trick to being able to have a PROC parm that is quoted but does not
need quadruple quotes? I tried the trick setting &Q to  and using that
instead of a literal quote and also a null parameter &X to fool JCL but
couldn't get those to work either.

I know we've been around on this sort of issue once or twice before ...

Thanks,

Charles Mills

--
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: Does anyone combine OMEGAMON and OMEGAVIEW in the same CSI?

[George Henke]

Yes, MCS, ty.

Also, IBM just got back to me and they highly recommend that they be in the
same CSI.

So now the question arises, it is better to reinstall the products or just
merge the CSI's via EXPORT, IMPORT, etc?

On Mon, Sep 13, 2010 at 3:57 PM, Paul Gilmartin wrote:

> On Mon, 13 Sep 2010 15:30:01 -0400, George Henke wrote:
>
> >Currently we have OMEGAMON and OMEGAVIEW in separate CSI's.
> >
> >Recently we applied a PTF to resolve an OC4 to OMEGAMON but the same PTF
> >also needed to be applied to OMEGAVIEW and was not.
> >
> >There are those who think had they been in the same CSI this problem would
> >not have occurred.
> >
> >If they are separate FMID's and even if in the same CSI and sharing the
> same
> >GLOBAL ZONE and PTS, and maybe even the same TARGET ZONE, I question
> whether
> >the PTF would have co-req'ed across FMID's.
> >
> Corequisites are commonly used across FMIDs within the same
> TARGET (or DLIB) zone.  That may even be the most frequent
> use.
>
> There are restrictions on applying a PTF to two different
> FMIDs in the same APPLY step, regardless that the PTF
> contains the needed ++VER statement.
>
> >But I guess that all depends on the UCL in the PTF.
> >
> ITYM MCS.
>
> --  gil
>
> --
> 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
>



-- 
George Henke
(C) 845 401 5614

--
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

Duplexing ISTGENERIC structure locked up sysplex

[Richards, Robert B.]

Just a heads up to those contemplating doing a duplex of ISTGENERIC. When I 
switched to the policy containing the duplex, all hell broke loose.

It is currently caught in REBUILD status and it is preventing "generic" logons 
to all systems in the SYSPLEX. If you are already logged on, you are fine.

All attempts to free it using SETXCF commands have been unsuccessful.

I will probably end up performing a sysplex-wide IPL in a few hours to resolve 
the situation.

If anyone has experienced duplexing problems with any other IBM MVS components, 
I would appreciate if you would drop me a note.

Bob

-
Robert B. Richards(Bob)
US Office of Personnel Management
1900 E Street NW Room: BH04L
Washington, D.C.  20415
Phone: (202) 606-1195
Email: robert.richa...@opm.gov
-

--
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: Does anyone combine OMEGAMON and OMEGAVIEW in the same CSI?

[Paul Gilmartin]

On Mon, 13 Sep 2010 15:30:01 -0400, George Henke wrote:

>Currently we have OMEGAMON and OMEGAVIEW in separate CSI's.
>
>Recently we applied a PTF to resolve an OC4 to OMEGAMON but the same PTF
>also needed to be applied to OMEGAVIEW and was not.
>
>There are those who think had they been in the same CSI this problem would
>not have occurred.
>
>If they are separate FMID's and even if in the same CSI and sharing the same
>GLOBAL ZONE and PTS, and maybe even the same TARGET ZONE, I question whether
>the PTF would have co-req'ed across FMID's.
>
Corequisites are commonly used across FMIDs within the same
TARGET (or DLIB) zone.  That may even be the most frequent
use.

There are restrictions on applying a PTF to two different
FMIDs in the same APPLY step, regardless that the PTF
contains the needed ++VER statement.

>But I guess that all depends on the UCL in the PTF.
>
ITYM MCS.

--  gil

--
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

SFTP Ported Tools

[Ken Porowski]

Just trying to get this working but the doc leaves much to be desired.

Note, our use of SFTP will probably be limited to internal use
(Mainframe to a common SFTP server within my network) so I'm not too
worried about duplication or sharing keys across multiple users.

Q1. Anyone know o a Redbook or presentation that takes you step by step?
I have the OpenSSH Users Guide from IBM.

Q2. Do I need to generate user keys or can I just use the host key?

Q3. For a user key does the user generating the key have to be the user
to use the key?  (i.e. can I (UID(0) or non (0)) generate all keys for
all users and just move them to the right files?

Q4. Can I copy the keys and change the human readable (i.e. the
hostname) portion at will? I won't touch the actual key.

Q5. I assume all sites I connect to will need my host (and user) keys,
Can I just email the .pub files or do I need to extract them into a
special format (ssh-keygen -e)

Q6. Do I need to use pass phrases or can I leave them null.

I have been RTFM but it is unclear on the above items and seems overly
complicated.

Thanks all

Ken Porowski
VP Mainframe Administration
CIT Group



--
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: z/OS non-sms dasd allocation algorithm ?

[Mark Zelden]

On Mon, 13 Sep 2010 12:37:25 -0500, Steve Mann  wrote:

>Does anyone know how a dasd volume is selected for a new non-sms dataset
>allocation when using the UNIT parm?  Is it  just the first volume in the UNIT
>group that satisfies the space request or is some other algorithm used?
>Anyone know if this is documented anywhere (IBM manual)?  z/OS 1.9
>

No, not the first volume.  The best performing device.  The algorithms used
are not documented that I know of, but there is a little bit about it in the 
MVS Initialization and Tuning Guide:

3.2.4.7 DASD Device Allocation

"Device allocation selects the most responsive DASD devices as candidates
for permanent data sets on mountable devices ...


See the manual for the remainder for the discussion.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
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: z/OS non-sms dasd allocation algorithm ?

[Mike Schwab]

VATLST sets up PUBLIC and STORAGE non-sms volumes.  PRIVATE volumes
are not used unless specifically requested.

On Mon, Sep 13, 2010 at 12:37 PM, Steve Mann  wrote:
> Does anyone know how a dasd volume is selected for a new non-sms dataset
> allocation when using the UNIT parm?  Is it  just the first volume in the UNIT
> group that satisfies the space request or is some other algorithm used?
> Anyone know if this is documented anywhere (IBM manual)?  z/OS 1.9
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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

OMEGAMON & OMEGAVIEW in same CSI: Pros and Cons?

[George Henke]

-- 
George Henke
(C) 845 401 5614

--
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: z/OS non-sms dasd allocation algorithm ?

[John H Kington]

Steve,

>Does anyone know how a dasd volume is selected for a new non-sms dataset
>allocation when using the UNIT parm?  Is it  just the first volume in the UNIT
>group that satisfies the space request or is some other algorithm used?
>Anyone know if this is documented anywhere (IBM manual)?  z/OS 1.9
>
You are asking for information on non-specific, non-sms dasd dataset allocation.
I don't know anyplace where everything is fully documented but you can use
the above to search the archives.

Assuming you are allocating a permanent dasd dataset and you have no third
party product that is directing/controlling allocation, the system will build a
candidate list of volumes associated with the unit that are mounted storage.
The list is then sorted by device delay (iosqueue time, pending time and
disconnect time) from lowest to highest. Allocation then occurs on the
first volume in the sorted list that has sufficient space in five extents or 
less.

Regards,
John

NOTICE:  The information contained in this electronic mail transmission is 
intended by Convergys Corporation for the use of the named individual or entity 
to which it is directed and may contain information that is privileged or 
otherwise confidential.  If you have received this electronic mail transmission 
in error, please delete it from your system without copying or forwarding it, 
and notify the sender of the error by reply email or by telephone (collect), so 
that the sender's address records can be corrected.

--
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

z/OS non-sms dasd allocation algorithm ?

[Steve Mann]

Does anyone know how a dasd volume is selected for a new non-sms dataset 
allocation when using the UNIT parm?  Is it  just the first volume in the UNIT 
group that satisfies the space request or is some other algorithm used?  
Anyone know if this is documented anywhere (IBM manual)?  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: S906-08

[Gerhard Postpischil]

On 9/13/2010 10:35 AM, Bill Fairchild wrote:

step, testing a program that does only a SYNCH macro to see
if the system can survive.


The problem was fixed in MVS with the introduction of LSQA and 
the E04 abend code.


But the SYNCH macro is overkill, a bare SVC 12 suffices. 
On a 4 meg 360/65 it took almost an hour to crash MVT.

Gerhard Postpischil
Bradford, VT

--
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: DSFORT INTERNAL ERROR WITH ICE185A S0C1 -HELP>

[Frank Yaeger]

Tommy Tsui on IBM Mainframe Discussion List  wrote on
09/12/2010 01:08:08 AM:
> >> After migrated to z/os 1.11 we found lot of  jobs using DFSORT
> >> icetools abended with ICE185A S0C1 "ABEND WAS ISSED BY DFSORT"

Please open a PMR with IBM service so we can collect the needed
doc and determine if it's a known problem.  IBM-MAIN is not the
appropriate place to pursue this.

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

--
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: CA ESP Workload Automation

[Norman Hollander on DesertWiz]

Out of curiosity, what's the issue(s) with Tivoli?  I'm familiar with all of
CA's and Tivoli's products.

zNorman

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Steve Dover
Sent: Monday, September 13, 2010 Monday 5:13 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CA ESP Workload Automation

On Fri, 10 Sep 2010 16:37:04 -0500, gsg  wrote:

>Does anyone use a CA job scheduler product called ESP Workload
Automation?
>
>PROS/CONS compared to other job schedulers?
>
>TIA
>
>--
>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

Worked at a company previously that used ESP, before CA bought the product.
I found it to be a very user friendly, reliable product.  Cybermation, the
original developer, was a little player in a big market.  We had used
another scheduling product that had been bought by CA and was being phased
out.  Our schedulers tried every scheduling product over a long (9 months I
think) time and ESP was the clear winner.  I am using Tivoli now and wish we
could convert to ESP.

--
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

--
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: z/OS V1.12 differences and z196 (the new mainframe) impacts

[Steve Comstock]

On 9/13/2010 8:22 AM, Paul Gilmartin wrote:

On Mon, 13 Sep 2010 07:33:13 -0600, Steve Comstock wrote:


R1 does not matter. From the Assembler Services Guide:

Unless otherwise defined by the individual interface, the
calling program should expect, upon return, that
* The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged
* The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged
.

Clarification:  I'm not thinking of system services, but of a
putative user program, AMODE 31, which has hitherto guaranteed
that R1 is preserved.


Well guaranteeing that R1 is preserved does not follow
the conventional standard (see quoted above), so it
would be a rare program that did so.

Furthermore, if this is a traditional program, it
really was really only guaranteeing the low word
(rightmost 32 bits) because it never had to concern
itself with the lefmost 32 bits; in the code below,
the low word is still maintained.

I've been around long enough to never say never, because
programmers will do the strangest things. But for all
practical terms I can't see this raises any potential
problems and it provides a nice little option for
programs that want to run in AMODE64. (Recall that
GETMAIN can't allocate storage above the bar, this
new feature simply ensures the effective address is
a 64-bit address if that's helpful.)


It does the conventional:


 STMR14,R12,12(R13)
 GETMAIN
 ...
 Stuff
 ...
 FREEMAIN
 LM R14,R12,12(R13)
 BR R14

Suddenly, with no change in either the calling or the called
code, the caller will find that the top half of R1 is destroyed.

-- gil



--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

--
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 vs. JES3

[Jack Schudel]

My copy of the Program Contribution Form for
/HASP-II/ HOUSTON AUTOMATIC SPOOLING PRIORITY SYSTEM WITH REMOTE JOB ENTRY
dated 10 SEP 1968
lists the authors as
Tom H. Simpson
Robert P. Crabtree
Robert O. Ray

There were spaces on the form for up to 4 authors, so I don't know why Dick 
Hitt was not listed.
Simpson, Crabby and Hitt were all regulars at SHARE back in the pre-MVS 
days, but I don't remember Robert O. Ray.  (My first SHARE was in 1976, long 
after the release of HASP-I V1 in July of 1967, so a lot could have happened 
in that time.)


The first Sing-a-Long was in Atlantic City, OCT 1968, with Dick Hitt at the 
piano, so he was clearly part of the team at that time.


PS: The full history of release dates is at the bottom of 
SYS1.AHASMAC($HASPEQU).


Any information about Robert O. Ray would be appreciated.

Thanks!

Jack Schudel
University of Florida
former SHARE JES2 Project Manager


- Original Message - 
From: "Bill Fairchild" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Monday, September 13, 2010 10:23 AM
Subject: Re: JES2 vs. JES3


One of the other two was Dick Hitt, who also played the piano during the 
Esprit de Corps sessions at the Thursday night SCIDS at SHARE until the 
Spring, 1982 meeting in LA, when Anne Caluori began playing.


Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On 
Behalf Of Shmuel Metz (Seymour J.)

Sent: Saturday, September 11, 2010 8:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: JES2 vs. JES3

In <20100909135157.e41821a...@mail.ase.com.au>, on 09/09/2010
  at 11:26 PM, Graeme Gibson  said:


ISTR hearing, circa 1967, that ASP had its roots in the 7xxx world,
with a 1440 or some other 14xx series machine(s) used as the
"Attached Support Processors" effectively doing the card and printer
I/O to relieve the main processor(s?) of these I/O intensive
tasks.


Direct Couple System (DCS) used a 7040 to drive a 7090 or a 7044 to
drive a 7094[1]; a 1401, 1440 or 1460 wouldn't have been fast enough.
I might believe that the code was ported to a 1410/7010, but that
would have been a total rewrite.


I also most definitely heard in a presentation in 1967 on HASP
("Houston Automatic SPool" or some such, Shmuel will know)


Priority.


four SEs in IBM's Houston office.


Simpson, Crabtree and who else?

[1] There's nothing in the code that would have prevented a
   7040/7094 or 7044/7090 pairing, but the first would have been
   to slow and the second too expensive.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

--
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



--
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 new POO (Props / ProP ) is available

[Scott Rowe]

I have a single IBM ID that is registered for IBMLink, Shopz and ResourceLink.  
I logged onto IBMLink earlier, and when I clicked on the link I worked fine 
without even asking me to logon again.

>>> "Chase, John"  9/7/2010 8:45 AM >>>
> -Original Message-
> From: IBM Mainframe Discussion List [On Behalf Of zMan
> 
> I even just tried creating a new ID, which still doesn't work. And
> used IE instead of Firefox. Something is busted.

Indeed.  So much for the "single IBM Sign-on" ID concept.  IBM
apparently has reached a point where it has too many "left hands" that
aren't aware even of the concept that "right hands" might exist.

So now I have one ID for IBMLink, a second for ShopzSeries, and now a
third that doesn't work for anything.

What incomprehensible BULLSHIT!!

   -jc-

--
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 



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


--
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: IBM and Texas Outsourcing troubles part two

[Howard Brazee]

On 10 Sep 2010 14:03:27 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote:

>The question should be:
>"How can we deliver our product/service most effectively?".
>
>Unfortunately, the question asked is:
>"What can we out-source, this year?"

Those are subsets of "How can we show on our resume how we dropped
costs - then get our raise or new job before those costs have been
properly evaluated over the long run - when it's someone else's
problem?".

--
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: CF Structures - ALLOWAUTOALT

[Richards, Robert B.]

Oops!

I meant *WITHOUT* ALLOWAUTOALT.

Bob


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Richards, Robert B.
Sent: Monday, September 13, 2010 10:54 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CF Structures - ALLOWAUTOALT

Did that (SETXCF START,REALLOCATE) and it would *not* effect the change with 
ALLOWAUTOALT, hence my question.

Bob


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Vernooij, CP - SPLXM
Sent: Monday, September 13, 2010 10:47 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CF Structures - ALLOWAUTOALT

"Richards, Robert B."  wrote in message
news:<2d14e7856646224aacdda13ab1d355570c8b92e...@wdcv7exvs2.opm.gov>...
> Is anyone using this and if so, have you seen any downside?
>
> I have a structure out there with policy change pending and it is
always allocated. User wants larger size and we are taking the default
of NO for all structures.
>
> Please advise.
>
> Bob
>

You can use the SETXCF command to initiate a rebuild for the structure
to effectuate the pending policy change.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
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

--
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

--
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: CF Structures - ALLOWAUTOALT

[Richards, Robert B.]

Did that (SETXCF START,REALLOCATE) and it would *not* effect the change with 
ALLOWAUTOALT, hence my question.

Bob


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Vernooij, CP - SPLXM
Sent: Monday, September 13, 2010 10:47 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CF Structures - ALLOWAUTOALT

"Richards, Robert B."  wrote in message
news:<2d14e7856646224aacdda13ab1d355570c8b92e...@wdcv7exvs2.opm.gov>...
> Is anyone using this and if so, have you seen any downside?
> 
> I have a structure out there with policy change pending and it is
always allocated. User wants larger size and we are taking the default
of NO for all structures.
> 
> Please advise.
> 
> Bob
> 

You can use the SETXCF command to initiate a rebuild for the structure
to effectuate the pending policy change.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
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

--
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: CF Structures - ALLOWAUTOALT

[Vernooij, CP - SPLXM]

"Richards, Robert B."  wrote in message
news:<2d14e7856646224aacdda13ab1d355570c8b92e...@wdcv7exvs2.opm.gov>...
> Is anyone using this and if so, have you seen any downside?
> 
> I have a structure out there with policy change pending and it is
always allocated. User wants larger size and we are taking the default
of NO for all structures.
> 
> Please advise.
> 
> Bob
> 

You can use the SETXCF command to initiate a rebuild for the structure
to effectuate the pending policy change.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
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: What is the difference in z/OS 1.12 Base and z/OS 1.12 Alternate Base?

[John Eells]

drink wrote:

A SHARE presentation says to order one or the other and to be sure to
order the right one.

But, what is the difference?


The short answer is most likely, "Order the one you had before--and that 
is almost certainly the z/OS 1.12 Base."  (There are vanishingly few 
orders for the Alternate Base.)


For the longer answer, someone else already pointed you to z/OS Planning 
for Installation.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
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

CF Structures - ALLOWAUTOALT

[Richards, Robert B.]

Is anyone using this and if so, have you seen any downside?

I have a structure out there with policy change pending and it is always 
allocated. User wants larger size and we are taking the default of NO for all 
structures.

Please advise.

Bob

-
Robert B. Richards(Bob)
US Office of Personnel Management
1900 E Street NW Room: BH04L
Washington, D.C.  20415
Phone: (202) 606-1195
Email: robert.richa...@opm.gov
-

--
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: S906-08

[Bill Fairchild]

Perhaps the OP deliberately put a simple test program into an infinite LOAD 
loop just to see what would happen.  I find that much more likely.  I have done 
similar things in the past; e.g., trying to run a job step with N and then N+1 
DD statements, where N is the documented maximum number per step, testing a 
program that does only a SYNCH macro to see if the system can survive.

IBM has a huge number of test job streams that they run against each new 
release of z/OS to make sure that all previously fixed APARs are still fixed, 
that no fixes have regressed, etc.  I'm sure many of them test various 
documented system limits.

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Gerhard Postpischil
Sent: Friday, September 10, 2010 11:59 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: S906-08

However, you either have 32K concurrent users of IEFBR14, 
something I find unlikely, or a long-running task that fails to 
do a DELETE. While theoretically a storage overlay is possible, 
it's unlikely to hit only the count field.

--
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?

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of 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.

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.

> 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.

Seems you've already observed that, in the case of multiple load modules
with the same name in a concatenation, the system uses the first
occurrence.  So, as to which entry in that load module would be used "by
name", it would be the one pointed to by the ESD entry in that first
load module.

> 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?)

Are you saying that the customer also has a test system, and that the
customer's test system connected successfully to your test system when
the customer's test system did not have the "customized" version of
ISTINCLM?  If that's the case, AND it's also the case that the
customer's test and production systems "are supposed to be identical",
then it seems the "cleanest" solution would be to simply rename the
customized ISTINCLM, verify that "everything works" using only the
IBM-supplied ISTINCLM, then delete the old one.

> 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.

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

Re: CICS 4.1 ServerPac and XLMGNR8

[John Eells]

R.S. wrote:

I have a problem with job XLMGNR8 which is a part of ServerPac for CICS
TS 4.1.
It should create some report in XML format, the job is optional by the way.

The job indefinitely fills output dataset by repeatedly putting an entry
describing SMPWRK6 dataset.

Has anyone found the problem? Is it a lack of service?



You could open a PMR.

But since XMLGNR8 was designed to create an XML description for use by 
msys for Setup, which is history, you might also choose to skip the job. 
 Unless, of course, you have some other use for the generated XML or 
have some local standard that requires all the jobs to be run.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
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: CA ESP Workload Automation

[Alan Schenck]

We have ESP, though I'm not all that familiar with it.  If you wish you can 
send me questions off list and I'd be glad to discuss with those in the know.

--
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: z/OS V1.12 differences and z196 (the new mainframe) impacts

[Paul Gilmartin]

On Mon, 13 Sep 2010 07:33:13 -0600, Steve Comstock wrote:
>
>R1 does not matter. From the Assembler Services Guide:
>
>Unless otherwise defined by the individual interface, the
>calling program should expect, upon return, that
>* The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged
>* The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged
>.
Clarification:  I'm not thinking of system services, but of a
putative user program, AMODE 31, which has hitherto guaranteed
that R1 is preserved.  It does the conventional:

STMR14,R12,12(R13)
GETMAIN
...
Stuff
...
FREEMAIN
LM R14,R12,12(R13)
BR R14

Suddenly, with no change in either the calling or the called
code, the caller will find that the top half of R1 is destroyed.

-- gil

--
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 vs. JES3

[Bill Fairchild]

One of the other two was Dick Hitt, who also played the piano during the Esprit 
de Corps sessions at the Thursday night SCIDS at SHARE until the Spring, 1982 
meeting in LA, when Anne Caluori began playing.

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Saturday, September 11, 2010 8:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: JES2 vs. JES3

In <20100909135157.e41821a...@mail.ase.com.au>, on 09/09/2010
   at 11:26 PM, Graeme Gibson  said:

>ISTR hearing, circa 1967, that ASP had its roots in the 7xxx world, 
>with a 1440 or some other 14xx series machine(s) used as the 
>"Attached Support Processors" effectively doing the card and printer 
>I/O to relieve the main processor(s?) of these I/O intensive
>tasks.

Direct Couple System (DCS) used a 7040 to drive a 7090 or a 7044 to
drive a 7094[1]; a 1401, 1440 or 1460 wouldn't have been fast enough.
I might believe that the code was ported to a 1410/7010, but that
would have been a total rewrite.

>I also most definitely heard in a presentation in 1967 on HASP 
>("Houston Automatic SPool" or some such, Shmuel will know)

Priority.

>four SEs in IBM's Houston office. 

Simpson, Crabtree and who else?

[1] There's nothing in the code that would have prevented a
7040/7094 or 7044/7090 pairing, but the first would have been
to slow and the second too expensive.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

--
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: Issuing WTOR SVC In Multitask Environment

[Bill Fairchild]

Perhaps the OP wants to learn more about how z/OS works.  Until I see more 
explanation of the ultimate goal, I would suggest running your z/OS under VM or 
possibly on whatever today's equivalent of a P/390 is.  That way, you can take 
steps to ensure that your task does not lose control to another task until the 
WTOR is replied to.

You can run through all ASCBs and TCBS and mark all TCBs non-dispatchable if 
you want; but the operator's reply command will not be read by the console 
communications task if it is non-dispatchable and/or if you have masked off all 
I/O interrupts on all active CPUs.  More explanation of what you really need to 
do would help us help you more.

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Ted MacNEIL
Sent: Sunday, September 12, 2010 4:52 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Issuing WTOR SVC In Multitask Environment

>Its only for testing

Testing what?
If you're not going to put it in Production, what is the purpose?

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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

--
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: Jobclas Protection - IEFUJI

[Jousma, David]

I mentioned the use of TSO submit exit, ONLY as a "early reminder" that
the user job is going to fail.   The real gatekeeper is IEFUJI.

_
Dave Jousma
Assistant Vice President, Mainframe Services
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB1G
p 616.653.8429
f 616.653.8497

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Walt Farrell
Sent: Monday, September 13, 2010 9:46 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Jobclas Protection - IEFUJI

On Fri, 10 Sep 2010 13:57:36 -0500, Rick Fochtman 
wrote:

>I can't help with the RACF/IEFUJI mechanism, but I do have a TSO SUBMIT
>exit that enforces job classes
>based on USERID. You're welcome to a copy by private mail if you'll
send
>me a private address for it.

I know someone has mentioned this recently, but I don't remember where,
so
at the risk of seeming repetitious I'll mention that the TSO SUBMIT exit
is
easily bypassed.  Simply write the job directly to an INTRDR. 

So if you really want control you need to use JES or SMF exits.

-- 
Walt Farrell
IBM STSM, z/OS Security Design

--
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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
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: Jobclas Protection - IEFUJI

[Walt Farrell]

On Fri, 10 Sep 2010 13:57:36 -0500, Rick Fochtman  wrote:

>I can't help with the RACF/IEFUJI mechanism, but I do have a TSO SUBMIT
>exit that enforces job classes
>based on USERID. You're welcome to a copy by private mail if you'll send
>me a private address for it.

I know someone has mentioned this recently, but I don't remember where, so
at the risk of seeming repetitious I'll mention that the TSO SUBMIT exit is
easily bypassed.  Simply write the job directly to an INTRDR. 

So if you really want control you need to use JES or SMF exits.

-- 
Walt Farrell
IBM STSM, z/OS Security Design

--
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: z/OS V1.12 differences and z196 (the new mainframe) impacts

[Steve Comstock]

On 9/13/2010 7:23 AM, Paul Gilmartin wrote:

On Mon, 13 Sep 2010 06:35:45 -0600, Steve Comstock wrote:


* GETMAIN now returns address of gotten area in R1 with the
   leftmost word being all binary zeros, so address can be
   treated as a 64-bit address


Unconditionally?  That would break subroutines that don't
save/restore high order parts.  (Or does R1 not matter?)

-- gil


R1 does not matter. From the Assembler Services Guide:

Unless otherwise defined by the individual interface, the
calling program should expect, upon return, that
* The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged
* The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged
.
.
.
* When return information is provided in GPR 0, 1, and/or 15
  (for example return and reason codes), only bits 32-63 of
   the register contain the returned value.

[Interesting, returning a 64-bit address in R1 would seem
 to violate that last assurance; perhaps a system service
 such as GETMAIN is not on a par with a general subroutine;
 in any case, I can't see this new behavior as causing any
 harm to programs that follow these classic requirements.

 On further reflection, there is still the opening caveat:
 "Unless otherwise defined by the individual interface".]


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

--
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: z/OS V1.12 differences and z196 (the new mainframe) impacts

[Paul Gilmartin]

On Mon, 13 Sep 2010 06:35:45 -0600, Steve Comstock wrote:
>
>* GETMAIN now returns address of gotten area in R1 with the
>   leftmost word being all binary zeros, so address can be
>   treated as a 64-bit address
>
Unconditionally?  That would break subroutines that don't
save/restore high order parts.  (Or does R1 not matter?)

-- gil

--
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: GTF trace help / SLIP trace capture

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of O'Brien, David W. 
> (NIH/CIT) [C]
> Sent: Monday, September 13, 2010 7:50 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: GTF trace help / SLIP trace capture
> 
> Diagnosis: Tools and Service Aids?
> 
> In the z/OS V1R11.0 MVS Bookshelf
> 
> Thank You,

Thanks!

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
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?

[John P. Baker]

Martin,

In examining the assembly output of a VTAM modetab, I observe that there is
no index generated.

Based upon the lack of an index, and the fact that there exists no
requirement to put the entries in alphabetical order, I would conclude that
VTAM will select the first matching entry from the table, and that
subsequent matching entries will be ignored.

John P. Baker

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Martin Kline
Sent: Friday, September 10, 2010 1:40 PM
To: IBM-MAIN@bama.ua.edu
Subject: How does VTAM handle duplicate MODEENT names in a logmode table?

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: How does VTAM handle duplicate MODEENT names in a logmode table?

[Staller, Allan]

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?)


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.

HTH,

--
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: GTF trace help / SLIP trace capture

[O'Brien, David W. (NIH/CIT) [C]]

Diagnosis: Tools and Service Aids?

In the z/OS V1R11.0 MVS Bookshelf

Thank You,
Dave O'Brien
NIH Contractor

From: McKown, John [john.mck...@healthmarkets.com]
Sent: Monday, September 13, 2010 8:47 AM
To: IBM-MAIN@bama.ua.edu
Subject: GTF trace help / SLIP trace capture

I can't find the stupid book on how to set the GTF options. Has anyone here 
ever run GTF to capture TRACE events from a SLIP trap? The SLIP is from IBM on 
a DFSORT problem and looks like:


SLIP SET,IF,ACTION=TRACE,LPAMOD=(ICEIPUT,550A4,55560),TRDATA=(STD,REGS),END



I'm just not off to a good start this week. A pointer to the correct manual 
would be gratefully received.


John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


--
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

--
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

GTF trace help / SLIP trace capture

[McKown, John]

I can't find the stupid book on how to set the GTF options. Has anyone here 
ever run GTF to capture TRACE events from a SLIP trap? The SLIP is from IBM on 
a DFSORT problem and looks like:


SLIP SET,IF,ACTION=TRACE,LPAMOD=(ICEIPUT,550A4,55560),TRDATA=(STD,REGS),END



I'm just not off to a good start this week. A pointer to the correct manual 
would be gratefully received.


John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


--
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

z/OS V1.12 differences and z196 (the new mainframe) impacts

[Steve Comstock]

For the last five or six years, August / September has been
a very busy time for me. This is when the IBM publications
for the new release of z/OS become available, and I download
these pubs and read them, looking for changes that impact
your applications programmers.

Then I update the courses I'm responsible for wherever the new
changes impact the course content.

Then I publish a brief synopsis of these changes to my opt-in
list and then various listservs and individual clients. So here
we go ...


This year the new release of z/OS is V1R12. There were
only a few aspects that may be useful to the typical
application programmer. But the availability of the new
mainframe line, the z196, impacts several of my courses.

The usefulness of any particular feature will vary from
person to person, of course; I figure if you see something
that looks helpful to you that you can check the docs
(or, of course, schedule a class!)

Highlights:

* New mainframe adds over 100 hardware instructions
* Minor changes to some z/OS UNIX commands
* New C/C++ functions to work with dates after 2038
* New VSAM ability to reclaim unused space dynamically


As usual, all of my courses that discuss any of the above
topics have been updated to reflect these changes /
enhancements. Let me know if you're aware of any other
training vendor who does that!




Now, for the next level of detail ...


_For the Assembler programmer in you_

The new z196 system introduces over 100 new instructions!

Discussion of these have been folded into the fourth course of
my z/OS Assembler series of courses; I've also re-named these
courses (while retaining the general content), so now the
curriculum is:

C410 z/OS Assembler Programming Part 1: Beginnings
C414 z/OS Assembler Programming Part 2: Interfaces
C416 z/OS Assembler Programming Part 3: Update
C500 z/OS Assembler Programming Part 4: z/Architecture and z/OS

visit

  http://www.trainersfriend.com/Assembler_%20courses/assemcurric.htm

for details


Also added to the last course in the above list:

* BSAM READ and WRITE allow buffer above the bar,
  using new paramter SF64 or SF64P


* CALL, LINK, LINKX, XCTL, XCTLX now document parameters
   PLIST4={YES|NO} - parameter list entries are 4 bytes or not
   PLIST8={YES|NO} - parameter list entries are 8 bytes or not
   PLIST8ARALETS={YES|NO}
 - for caller in AR mode, YES indicates 8 bytes-per-entry
 parameter list is to be followed by the 4 bytes-per-entry
 ALET list


* Macro IEABRCX extends IEABRC:

IEABRCX  {DEFINE|PUSH|DISABLE|ENABLE|POP}


* GETMAIN now returns address of gotten area in R1 with the
  leftmost word being all binary zeros, so address can be
  treated as a 64-bit address


* Binder RMODE option has new suboption {INITIAL|COMPAT}
  for use when RMODE(SPLIT) is not used; INITIAL indicates
  RMODE value applies to all initial load classes in all
  segments, while COMPAT indicates the RMODE value applies
  to all initial load classes in the first segment only

  (Beats the heck out of me what the practical implications are!)



_Various interesting developments_

Support for EAV (Extended Address Volumes) continues
to expand; with this release, the following kinds of
data sets may reside in the Extended Address Space
(EAS) of EAVs: VSAM, zFS (but not HFS), sequential,
PDS, PDSE, BDAM, and data sets with undefined DSORGs;
this is still not for VTOCs, VTOC indices, or page
data sets.


Support for the Large Block Interface (LBI) (blocksizes
greater than 32K) has been enhanced, sort of. We find
this somewhat contradictory paragraph in the Using
Data Sets publication:

"The large block interface (LBI) lets your
 program handle much larger blocks with BSAM
 or QSAM. On the current level of the system
 you can use LBI with BSAM, BPAM, and QSAM
 for any kind of data set except unit record
 or a TSO/E terminal. Currently blocks of more
 than 32 760 bytes are supported only on tape,
 dummy data sets, and BSAM UNIX files."

The last sentence seems to negate the previous sentence.
So, does LBI currently support BPAM? Apparently so,
but only if the data set is on tape. But, of course,
tape does not support BPAM.



Support for the new HFS / zFS filetype of RECORD
is expanded by being included in various shell commands
(e.g.: cp, extattr, ls, mv)


The ohelp command is removed from omvs; the intent
aparently is: you should use the 'man' facility


The tsocmd shell command can run authorized TSO commands


The oedit command has been modified so it doesn't
support the source ascii command; to edit an ASCII file
you must use file tagging and tag the file as ISO-8859-1


There are nine new environment variables for use
in the C/C++ run-time for setting run time options
and such


There are new C/C++ functions to work with date/times
beyond the January 19, 2038 end of era date range; the
limit for these new functions is December 31, 



C/C++ compiler now supports:
 * compile option to generate z196 instructions
 * compile o

Re: CA ESP Workload Automation

[Steve Dover]

On Fri, 10 Sep 2010 16:37:04 -0500, gsg  wrote:

>Does anyone use a CA job scheduler product called ESP Workload 
Automation?
>
>PROS/CONS compared to other job schedulers?
>
>TIA
>
>--
>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

Worked at a company previously that used ESP, before CA bought the 
product.  I found it to be a very user friendly, reliable product.  
Cybermation, 
the original developer, was a little player in a big market.  We had used 
another scheduling product that had been bought by CA and was being 
phased out.  Our schedulers tried every scheduling product over a long (9 
months I think) time and ESP was the clear winner.  I am using Tivoli now and 
wish we could convert to ESP.

--
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

Re: Channel path acronym's

[Miklos Szigetvari]

   Hi

Thank you very much
On 9/11/2010 7:43 PM, Barry Merrill wrote:

Here's MXG's past and present mappings for SMF73CPD values:


  /* $MG073CD FORMAT FOR VMAC73 */
  VALUE $MG073CD
   '00'X='00X:UNKNOWN'  /*UNDEF*/
   '01'X='01X:PARALLEL BLOCK MPX'   /*BLOCK*/
   '02'X='02X:PARALLEL BYTE MPX'/*BYTE*/
   '03'X='03X:ESCON POINT TO POINT' /*CNC_P*/
   '04'X='04X:ESCON SWITCHED OR POINT TO POINT' /*CNC_?*/
   '05'X='05X:ESCON SWITCHED POINT TO POINT'/*CNC_S*/
   '06'X='06X:ESCON PATH TO A BLOCK CONVERTER'  /*CVC*/
   '07'X='07X:NATIVE INTERFACE' /*NTV*/
   '08'X='08X:CTC POINT TO POINT'   /*CTC_P*/
   '09'X='09X:CTC SWITCHED POINT TO POINT'  /*CTC_S*/
   '0A'X='0AX:CTC SWITCHED OR POINT TO POINT'   /*CTC_?*/
   '0B'X='0BX:COUPLING FACILITY SENDER' /*CFS*/
   '0C'X='0CX:COUPLING FACILITY RECEIVER'   /*CFR*/
   '0D'X='0DX:UNKNOWN'  /*UNDEF*/
   '0E'X='0EX:UNKNOWN'  /*UNDEF*/
   '0F'X='0FX:ESCON PATH TO A BYTE CONVERTER'   /*CBY*/
   '10'X='10X:OSA EXPRESS'  /*OSE*/
   '11'X='11X:OSA DIRECT EXPRESS'   /*OSD*/
   '12'X='12X:OSA CHANNEL'  /*OSA*/
   '13'X='13X:INTERNAL SYSTEM DEVICE'   /*ISD*/
   '14'X='14X:HSSI OPEN SYSTEM ADAPTER CHANNEL' /*OSC*/
   '15'X='15X:ETHERNET OPEN SYSTEM ADAPTER CHANL'   /*OSN*/
   '16'X='16X:CLUSTER BUS SENDER'   /*CBS*/
   '17'X='17X:CLUSTER BUS RECEIVER' /*CBR*/
   '18'X='18X:INTERNAL COUPLING ISC SENDER' /*ICS*/
   '19'X='19X:INTERNAL COUPLING ISC RECEIVER'   /*ICR*/
   '1A'X='1AX:FICON POINT TO POINT' /*FC */
   '1B'X='1BX:FICON SWITCHED'   /*FC_S*/
   '1C'X='1CX:FICON TO ESCON BRIDGE'/*FCV*/
   '1D'X='1DX:FICON INCOMPLETE' /*FC_?*/
   '1E'X='1EX:DIRECT SYSTEM DEVICE' /*DSD */
   '1F'X='1FX:EMULATED I/O' /*EIO */
   '20'X='20X:RESERVED' /*UNDEF*/
   '21'X='21X:INTEGRATED CLUSTER BUS PEER'  /*CBP*/
   '22'X='22X:COUPLING FACILITY PEER'   /*CFP*/
   '23'X='23X:INTERNAL COUPLING PEER'   /*ICP*/
   '24'X='24X:INTERNAL QUEUED DIRECT COMM'  /*IQD*/
   '25'X='25X:FCT CHANNEL'  /*FCP*/
   '26'X='26X:COUPLING OVER INFINIBAND' /*CIB*/
   '30'X='30X:OSA ZBX DATA' /*OSX*/
   '31'X='31X:OSA ZBX MANAGEMENT'   /*OSM*/



Herbert W. Barry Merrill, PhD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas TX 75229
214 351 1966 tel
214 350 3695 fax
www.mxg.com

--
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




--
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