Re: NIP console devices limit

[R.S.]

Mark Zelden pisze:

On Mon, 12 Jan 2009 22:04:40 +0100, R.S.  wrote:


What is a limit of devices on NIP console list in IODF (OS Config) ?


Don't know.  Probably more than you need to define - even if you 
did what you describe below.   Maybe 99? 


Background:
A CPC with several LPARs defined. There are several OSA-ICC consoles
defined for each LPAR. However NIP console is assigned to OS Config
definition. There are many of them for different disk volume sets
(cloned volsers). The goal is to make possible to IPL given OS config on
any LPAR. WIth NIP consoles of course.
The only solution I can imagine is to define all the console devices for
all the LPARs on NIP console list. Which seems to me "overkill". Is
there simpler or more elegant method?



Can't you use the same addresses for each OS config? Or is that some sort
of OSA-ICC restriction.  All our LPARs use the same addresses, but we are
using 2074s.  


I vaguely remember, that addresses need to be unique (cannot be reused). 
However I have to check it again. It would be good idea.
From the other hand - what about MCS consoles? Two concurrently running 
systems (LPARs) cannot use same device as console. Assuming monoplexes.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA  wynosi 
118.642.672 zote i zosta w caoci wpacony.

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

Query on SUB-CAPACITY PLANNING TOOL data

[Tommy Tsui]

hi all,

After I ran the SCPT, I found many duplicate time record with
different R4 value. Is there something wrong on SCPT report?

"Date-Time of RMF
Datetime R4 for lpar
"30 Nov 08 - 06:05", 15
"30 Nov 08 - 06:10", 18
"30 Nov 08 - 06:10", 28
"30 Nov 08 - 06:15", 11
"30 Nov 08 - 06:20", 33
"30 Nov 08 - 06:20", 21

Thanks and regards

--
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: NIP console devices limit

[Lutz Hamann]

Radoslaw, 

yes - you can use shared OSC-devices as NIP-consoles in all LPAR's.

We implemented it here this way and it works without problem.


ciao  Lutz

--
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: NIP console devices limit

[Zaromil Tisler]

Hi Radoslaw,

> From the other hand - what about MCS consoles? Two concurrently running
>systems (LPARs) cannot use same device as console. Assuming monoplexes.

We also have OSA-ICC and all our LPAR use the same two device numbers for 
MCS consoles. But, these are NOT same devices: MIFID - Device Number 
combination (OSA-ICC session) on one CEC is unique.

Regards,
Žaromil

--
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: vsnprintf(); off by 1!?

[Paul Gilmartin]

On Mon, 12 Jan 2009 22:31:50 -0800, Henry Willard wrote:
>
>"memcpy( &ap, &xp, sizeof( va_list ) );" is not legal C. Either use the
>c99 va_copy ("va_copy(ap,xp)") created for this purpose or define
>_VARARG_EXT before including stdarg.h. Up until c99 there was no defined
>way to do what you were trying to do although your method as well as
>direct assignment worked on many but not all systems.
>
Thanks for educating me.  Hmmm...

#define _VARARG_EXT_

leads to:

Trying vsnprintf();
CEE3204S The system detected a protection exception (System Completion 
Code=0C4).
 From entry point f2 at compile unit offset +01A4 at entry offset 
+01A4 at address 448CCADC.
[1] + Done(139) gmake varg && ./varg
  67109204  Segmentation violation  ./varg

... a step backward.  If vsnprintf() is incompatible with _VARARG_EXT_,
it would be a courtesy to the programmer to manifest this at compile
time, possibly by using char** instead of va_list to expose the
incompatibility.

I see that va_copy() is defined as:

  #define va_copy(dest, src) ((dest) = (src))

... simple enough.  But our systems programmer hasn't configured
the c99 environment.

If I undefine and redefine va_start, adding a call to va_arg at
the end, it works OK.  But my real goal is to get it working in
enhanced ASCII mode.  And that fails with:

c89 -I.. -D_ALL_SOURCE   -Wa,"ASA,RENT" -Wl,xplink,EDIT=NO -Wc,dll,ascii   -o 
varg ../source/varg.c /usr/lib/Xaw.x /usr/lib/SM.x /usr/lib/ICE.x 
/usr/lib/X11.x -lcurses
-sh 0 + ./varg
-sh 0 + 2<& 1
-sh 0 + iconv -f ISO8859-1 -t IBM-1047
CEE3204S The system detected a protection exception (System Completion 
Code=0C4).
 From entry point f2 at compile unit offset +0060 at entry offset 
+0060 at address 448F0190.
Format: " %s -- %s "

Thanks,
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: Is this PPRC or Flashcopy?

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

Thanks all for your responses.

The issue was resolved offline. We are using PPRC commands (Cestpair etc) 
within the 9990V which requires ShadowImage.


From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Ted 
MacNEIL [eamacn...@yahoo.ca]
Sent: Tuesday, January 13, 2009 1:48 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Is this PPRC or Flashcopy?

>There are many ways to skin a cat. You can Flashcopy first and then PPRC
it. Or flashcopy and PPRC from same source (set of volumes).

Yes, but.
My understanding of the OP's question was that they wanted to remote copy off 
of the flashcopy.
You can't skin that cat.
If I misread, sorry.

-
Too busy driving to stop for gas!

--
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: NIP console devices limit

[R.S.]

Zaromil Tisler pisze:

Hi Radoslaw,


From the other hand - what about MCS consoles? Two concurrently running
systems (LPARs) cannot use same device as console. Assuming monoplexes.


We also have OSA-ICC and all our LPAR use the same two device numbers for 
MCS consoles. But, these are NOT same devices: MIFID - Device Number 
combination (OSA-ICC session) on one CEC is unique.


So I can use i.e. device 100 as console on each LPAR, but it is 
different device on each of them! So I could use such defined devices as 
MCS consoles as well as NIP consoles! Couldn't I?

That would seriously reduce complexity of my ICC setup.

However it seems weird for me: each MVS has UCB related to one(?) UCW in 
HSA. In fact there are several devices in CU (CUs). I don't feel it...


Last but not least:
Gentlemen thank you all for your responses! I appreciate all of them.
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA  wynosi 
118.642.672 zote i zosta w caoci wpacony.

--
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: NIP console devices limit

[Lutz Hamann]

Radoslaw,

that's the advantage of a shared OSC-channel, coding UNIT=OSC for the CU and
UNIT=3270,MODEL=X for the IODEVICE.

AFAIK normally you can't share the same address of a 3174-CU over all LPARs.
And yes, define i.e. 100 as your NIP-console and 101, 102 as MCS-consoles
(if you need 2 MCS-consoles) for every LPAR.

Configure your TN3270E-emualation to the OSC-channels IP-address and let the
LU-name (defined via OSA advanced facilities in your CEC) decide what device
in what LPAR to use ...


   ciao  Lutz

   

--
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: GRS CNS policy

[Arthur Gutowski]

On Fri, 9 Jan 2009 09:24:36 +0100, Tidy, David (D)  
wrote:

My 2 questions are:
>1) does anyone have a policy on GRS CNS positioning in their sysplex
>(and if so what is it and why)?
>2) otherwise does anyone have any opinion on whether it might make sense
>to position CNS in either the busiest or the quietest system in the
>sysplex (the former on the basis of reduced traffic, the latter on
>better CPU allocation)?

No hard and fast recommendations here, but you also want to consider:

Proximity to the GRS lock structure (ISGLOCK) - internal links are faster than 
external (caveat:  zero experience with Infiniband)
CF CPU utilization and other structures in the CF LPAR that houses ISGLOCK
Whether DYNDISP is ON or OFF for the CF LPAR housing ISGLOCK

IBM recommends DYNDISP OFF, but we're in sort of a catch-33 with our 
configuration for now...

Regards,
Art Gutowski
Ford Motor Company

--
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: First z/OS 1.9 IPL Problem

[Mark Zelden]

On Mon, 12 Jan 2009 04:37:34 -0500, Shmuel Metz (Seymour J.)
 wrote:

>In <84eb68c5090445q3dfa7449k71369f2942b71...@mail.gmail.com>, on
>01/12/2009
>   at 09:45 AM, Daz  said:
>
>>Are you positive about that? My book says to reply FORMAT,NOREQ for a
>>cold start, and just NOREQ for a warm.
>
>FORMAT takes much longer than a cold start.
>

Not for newly allocated HASPACE (which this is considering it was just
allocated as part of serverpac).  COLD implies fomat in this case, so it
is the same amount of time.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: NIP console devices limit

[Mark Zelden]

On Tue, 13 Jan 2009 13:52:19 +0100, R.S.  wrote:

>
>However it seems weird for me: each MVS has UCB related to one(?) UCW in
>HSA. In fact there are several devices in CU (CUs). I don't feel it...
>

Smoke and mirrors.  It's been that way since MVSCP.  2 LPARs can have
the same address that are 2 completely different physical devices or visa
versa if you want to make it really confusing to your operators!

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: MAXUSER=250

[Chris Mason]

John

Putting flesh on Ted's bare bone, here is a sample way to define TSO in the 
VTAM of the last - as Ted mentioned - decade and more:


 VBUILD TYPE=APPL
xxTSOAPPL  ACBNAME=TSO, interpreted and uninterpreted name *
   AUTH=(TSO,PASS), TSO + PASS *
   EAS=1,  generally one session at a time *
   FASTPASS=YES,  efficient PASS logic *
   REGISTER=CDSERVR register LU with CD server
xxTSO??? APPL  ACBNAME=TSO0???, interpreted and uninterpreted name *
   AUTH=(TSO,NVPACE),TSO + prevent outbound pacing *
   EAS=1,  one session *
   LOSTERM=SECOND,end session on second VARY INACT *
   MAXPVT=0,  no limit on PIUs pending RECEIVE *
   MODSRCH=FIRST, required model search option for TSO *
   REGISTER=NO, do not register LU *
   VPACING=0prevent inbound pacing

In addition to showing how to define the TSO-user-supporting sessions by 
means of a model APPL statement, I believe all relevant operands for TSO 
applications are shown with generally suitable values.

An exception to "generally" is MODSRCH=FIRST which is absolutely required - 
yes, I have a scar to remind me!. Indeed it's a shame that the VTAM 
developers weren't clever enough to make it the default when a model APPL 
statement is used and AUTH=TSO is specified.

Chris Mason

On Mon, 12 Jan 2009 19:37:18 +, Ted MacNEIL  
wrote:

>>F TSO,USERMAX=500 (for example)
>
>>It will change the amount.  But you need to change the VTAM number of 
entries to correspond with the increase.
>
>VTAM has had the capability for dynamic ACB's for awhile (over 10 years).

--
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: Is this PPRC or Flashcopy?

[John Kelly]

The C* commands above are documented as PPRC commands. No mention of 
Flashcopy. So why is my hardware vendor demanding that we be licensed for 
Flashcopy?


We're in the throes of this now. We have a UPS V with ShadowCopy but to 
use FlashCopy, we need to get HDS' 'compatible' FlashCopy, a charged 
license. Our vendor is VION. I'd like to talk to use off-list about how 
you relabel and dump for thr DR. Currently I can mirror the volumes then 
suspend the pair and as you indicate relabel and dump then resynch the 
pairs. This seems error prone and too manual. VION indicated our only 
option is to purchase FDRInstant or 'compatible' FlashCopy. 

Jack Kelly
202-502-2390 (Office)

--
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 1.10 upgrade stopped by RLS - SMSVSAM bug

[Jousma, David]

All,

Not sure how many of you are in our shoes, but we ran into a bug in
1.8(problem is in 1.9 too) toleration maintenance for RLS.  It involves
PSP bucket identified PTF's OA26534, OA27378, and OA26039.  Bottom line
is that IBM introduced MLS(Multiple Lock Structures) in 1.10 of SMSVSAM,
and the toleration maintenance for 1.8 and 1.9 is to support that.
There are severe performance problems with the toleration maintenance to
the point we cannot take it to our production environments.  First
iteration of the problem was elongated RLS dataset opens causing major
GRS enqueue delays, which IBM has developed a APARfix for, but that
APARfix now exhibits huge sustained CPU hits in SMSVSAM during dataset
opens by a factor of 10 or more.

Bottom line, is that we cannot move forward with 1.10 on any system in
the plex until this problem is cleared up.  Our PMR has been open since
10/10/08, with no end in sight.

Given the length of time our problem has been on the queue, there must
not be that many big RLS users out there.

Dave

_
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


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: z/OS 1.10 upgrade stopped by RLS - SMSVSAM bug

[Mark Zelden]

>Bottom line, is that we cannot move forward with 1.10 on any system in
>the plex until this problem is cleared up.  Our PMR has been open since
>10/10/08, with no end in sight.
>
>Given the length of time our problem has been on the queue, there must
>not be that many big RLS users out there.
>

I don't think that is true. But perhaps not many are ready to roll 1.10
to production yet.  We are a big RLS shop but just starting 1.10 now.  
We usually order in Dec. or Jan. after it has been out a while so 
shops like yours can work out the bugs for us.  :-)  

Actually, SMSVSAM has been behaving fairly well since post z/OS 1.3.  Or
at least the end of our z/OS 1.3 after many many PTFs were applied. 
We had problems all the time back then.  

Please keep us posted!

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: vsnprintf(); off by 1!?

[Don Poitras]

Paul Gilmartin wrote:
> 
> On Mon, 12 Jan 2009 22:31:50 -0800, Henry Willard wrote:
> >
> >"memcpy( &ap, &xp, sizeof( va_list ) );" is not legal C. Either use the
> >c99 va_copy ("va_copy(ap,xp)") created for this purpose or define
> >_VARARG_EXT before including stdarg.h. Up until c99 there was no defined
> >way to do what you were trying to do although your method as well as
> >direct assignment worked on many but not all systems.
> >
> Thanks for educating me.  Hmmm...
> 
> #define _VARARG_EXT_
> 
> leads to:
> 
> Trying vsnprintf();
> CEE3204S The system detected a protection exception (System Completion 
> Code=0C4).
>  From entry point f2 at compile unit offset +01A4 at entry offset 
> +01A4 at address 448CCADC.
> [1] + Done(139) gmake varg && ./varg
>   67109204  Segmentation violation  ./varg
> 
> ... a step backward.  If vsnprintf() is incompatible with _VARARG_EXT_,
> it would be a courtesy to the programmer to manifest this at compile
> time, possibly by using char** instead of va_list to expose the
> incompatibility.
> 
> I see that va_copy() is defined as:
> 
>   #define va_copy(dest, src) ((dest) = (src))
> 
> ... simple enough.  But our systems programmer hasn't configured
> the c99 environment.
> 
> If I undefine and redefine va_start, adding a call to va_arg at
> the end, it works OK.  But my real goal is to get it working in
> enhanced ASCII mode.  And that fails with:
> 
> c89 -I.. -D_ALL_SOURCE   -Wa,"ASA,RENT" -Wl,xplink,EDIT=NO -Wc,dll,ascii   -o 
> varg ../source/varg.c /usr/lib/Xaw.x /usr/lib/SM.x /usr/lib/ICE.x 
> /usr/lib/X11.x -lcurses
> -sh 0 + ./varg
> -sh 0 + 2<& 1
> -sh 0 + iconv -f ISO8859-1 -t IBM-1047
> CEE3204S The system detected a protection exception (System Completion 
> Code=0C4).
>  From entry point f2 at compile unit offset +0060 at entry offset 
> +0060 at address 448F0190.
> Format: " %s -- %s "
> 
> Thanks,
> gil

I believe you also need:

#define _ISOC99_SOURCE

as shown in the doc.

-- 
Don Poitras - zSeries R & D  -  SAS Institute Inc. -  SAS Campus Drive 
mailto:sas...@sas.com   (919)531-5637  Fax:677- Cary, NC 27513

--
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 1.10 upgrade stopped by RLS - SMSVSAM bug

[Jousma, David]

Thanks Mark, will do.  So, you have not put the toleration maintenance
on your current systems for 1.10 yet?  That is when we saw the problem,
and that was only in our DEV environment.  Never even got a chance in
production.  SMSVSAM has been good for us up to this point as well.  If
you have installed the maint, the problem only surfaces at cluster open
time, so if dataset opens at your shop are only sporadic, and not done
all at once, you may not be seeing the problem.  On our development
systems, where some of our online regions are bounced all the time, we
have 7000+ datasets registered in RLS, and my performance guy was
sitting on my doorstep the day after the fixes went on DEV, when he was
seeing SMSVSAM go from less than 10 MIPS to over 250 MIPS sustained
bursts.  IBM has found the source of the CPU sucking, it is when they
scan the "table" for a dataset name match in the lock structure.  The
IBM TEST group load tests in the lab with only 1000 datasets, and that
is why they didn't see the CPU jump I am being told.

Dave

_
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 Mark Zelden
Sent: Tuesday, January 13, 2009 10:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.10 upgrade stopped by RLS - SMSVSAM bug

I don't think that is true. But perhaps not many are ready to roll 1.10
to production yet.  We are a big RLS shop but just starting 1.10 now.  
We usually order in Dec. or Jan. after it has been out a while so 
shops like yours can work out the bugs for us.  :-)  

Actually, SMSVSAM has been behaving fairly well since post z/OS 1.3.  Or
at least the end of our z/OS 1.3 after many many PTFs were applied. 
We had problems all the time back then.  

Please keep us posted!

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

XML Parse Errors

[Vince Smith]

I am getting a XML CODE  of 001 on a COBOL XML Parse statement. Can 
someone point me to the manuals that list all of the error codes that can be 
generated from the COBOL XML Parse statement?

Thanks.

Vince
 

--
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 1.10 upgrade stopped by RLS - SMSVSAM bug

[Mark Zelden]

On Tue, 13 Jan 2009 10:41:17 -0500, Jousma, David  wrote:

>Thanks Mark, will do.  So, you have not put the toleration maintenance
>on your current systems for 1.10 yet?  That is when we saw the problem,
>and that was only in our DEV environment. 

Not yet.  Year end freeze until near the end of this month.

For general maintenance, we stay one quarter behind quarterly RSU so we
are only at RSU0806. So when RSU0812 comes out shortly we will 
apply RSU0809 and  I'm sure that includes much of the 1.10 compatibility /
toleration maintenance.  Of course we we will also explicitly apply maintenance 
identified with SMP/E 3.5 via
REPORT MISSINGFIX FIXCAT(IBM.Coexistence.z/OS.V1R10).   

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: XML Parse Errors

[Schneiderwent, Craig - DOT]

Which COBOL compiler?  If 4.1, did you compile with XMLPARSE(XMLSS) ?

The XML-CODE special register contains different values for the different 
parsers.  Looking at the codes, though, it appears you're either pre-4.1 or 
compiled with XMLPARSE(COMPAT).  So...

1 The parser found an invalid character while scanning white space outside 
element content.

Which is found in the Enterprise COBOL for z/OS V3.4 Programming Guide 
.

The XML-CODEs are documented at


and



URLs will no doubt wrap.

I wrote a COBOL program to do the translation of XML-CODE to the appropriate 
text.  Hopefully our XML PARSE coders will decide to use it.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on
Behalf Of Vince Smith
Sent: Tuesday, January 13, 2009 9:43 AM
To: IBM-MAIN@bama.ua.edu
Subject: XML Parse Errors


I am getting a XML CODE  of 001 on a COBOL XML Parse statement. Can
someone point me to the manuals that list all of the error codes that can be
generated from the COBOL XML Parse statement?

Thanks.

Vince


--
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: XML Parse Errors

[Steve Comstock]

Vince Smith wrote:
I am getting a XML CODE  of 001 on a COBOL XML Parse statement. Can 
someone point me to the manuals that list all of the error codes that can be 
generated from the COBOL XML Parse statement?


Thanks.

Vince


Appendix D of the COBOL Programmer's Guide has the list.
XML PARSE found an invalid character.

Go to:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG40/CCONTENTS?SHELF=EZ2ZS20L&DN=SC23-8529-00&DT=20071214180654

for Bookmanager and PDF versions or here:

http://www-03.ibm.com/systems/z/os/zos/bkserv/zswpdf/

for PDF versions; look for Enterprise COBOL


Our two-day course "Enterprise COBOL Update II: Unicode and XML Support"
covers all the idiosyncracies of using COBOL to parse and generate XML
data. The nine labs comprise a case study of parsing an XML transaction
into a classic record, passing this to an existing transaction handler,
and generating XML from the transaction handler response.

Look at:
http://www.trainersfriend.com/COBOL_Courses/d705descr.htm





Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

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

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> Check out the Trainer's Friend Store to purchase z/OS  <==
==> application developer toolkits. Sample code in four<==
==> programming languages, JCL to Assemble or compile, <==
==> bind and test. <==
==>   http://www.trainersfriend.com/TTFStore/index.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: XML Parse Errors

[Flint, Mike]

It's in the COBOL language reference manual - in one of the appendixes. 

 
┌┐
│ Table 89. XML PARSE exceptions that allow continuation
 │
├┬──┬┤
│ Code   │ Description  │ Parser action on continuation 
 │
├┼──┼┤
│ 1  │ The parser found an invalid  │ The parser continues 
detecting errors  │
││ character while scanning white space │ until it reaches the end of 
the│
││ outside element content. │ document or encounters an 
error that   │
││  │ does not allow continuation. 
The   │
││  │ parser does not signal any 
further │
││  │ normal events, except for the 
 │
││  │ END-OF-DOCUMENT event.
 │
├┼──┼┤


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Vince Smith
Sent: 13 January 2009 15:43
To: IBM-MAIN@bama.ua.edu
Subject: XML Parse Errors

I am getting a XML CODE  of 001 on a COBOL XML Parse statement. Can someone 
point me to the manuals that list all of the error codes that can be generated 
from the COBOL XML Parse statement?

Thanks.

Vince
 

--
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 has come from Experian, the only business to have been twice named 
the UK's 'Business of the Year’ 

===
Information in this e-mail and any attachments is confidential, and may not be 
copied or used by anyone other than the addressee, nor disclosed to any third 
party without our permission. There is no intention to create any legally 
binding contract or other binding commitment through the use of this electronic 
communication unless it is issued in accordance with the Experian Limited 
standard terms and conditions of purchase or other express written agreement 
between Experian Limited and the recipient. 
Although Experian has taken reasonable steps to ensure that this communication 
and any attachments are free from computer virus, you are advised to take your 
own steps to ensure that they are actually virus free. 
Companies Act information:
Registered name: Experian Limited 
Registered office: Talbot House, Talbot Street, Nottingham NG80 1TH 
Place of registration: England and Wales 
Registered number: 653331

--
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: NIP console devices limit

[Hal Merritt]

That's how we do it: every LPAR has the exact same console UCB definitions. 
Names are made unique via system symbols. The controllers (a Visara and an IBM 
2074) keep things straight. 

Note: we do not define consoles in the IODF/IOCDS. Any true NIP issues are 
dealt with from the HMC console facility. The interface is a little clugy (not 
all prompts appear), but it works well enough for a shop that never IPL's.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Mark Zelden
Sent: Tuesday, January 13, 2009 8:15 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: NIP console devices limit

On Tue, 13 Jan 2009 13:52:19 +0100, R.S.  wrote:

>
>However it seems weird for me: each MVS has UCB related to one(?) UCW in
>HSA. In fact there are several devices in CU (CUs). I don't feel it...
>

Smoke and mirrors.  It's been that way since MVSCP.  2 LPARs can have
the same address that are 2 completely different physical devices or visa
versa if you want to make it really confusing to your operators!

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

--
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 1.10 upgrade stopped by RLS - SMSVSAM bug

[Bill Wilkie]

Dave/Mark:
 
I saw a problem similar to what you are describing but it was in a custom 
application written for a very large customer by a very large vendor. The 
problem sounds the same so I will describe the one I encountered.
 
In the problem I saw they were inserting a record into a very large linked 
list. They acquired a lock before scanning the list looking for the insert 
point. As the list got longer, the amount of time that the lock was held became 
longer and similar transactions on other processors were SPINNING, awaiting the 
release of the lock. My suggestion was to scan the list first looking for the 
insert point, THEN acquire the lock, re-verify the insert point, do the insert 
and free the lock. That diminished the amount of time that the lock was held 
and fixed the problem. You can also check for excessive spin records to confirm 
this. 
 
In fact, a similar technique can be used when using the CS and CDS 
instructions. Instead of using the CS and CDS instructions to serialize on a 
memory location every time, you can use a normal compare till you find what you 
are looking for, then issue the CS or CDS to verify it is still the same. 
 
Bill 
 
 
> Date: Tue, 13 Jan 2009 10:41:17 -0500> From: david.jou...@53.com> Subject: 
> Re: z/OS 1.10 upgrade stopped by RLS - SMSVSAM bug> To: IBM-MAIN@bama.ua.edu> 
> > Thanks Mark, will do. So, you have not put the toleration maintenance> on 
> your current systems for 1.10 yet? That is when we saw the problem,> and that 
> was only in our DEV environment. Never even got a chance in> production. 
> SMSVSAM has been good for us up to this point as well. If> you have installed 
> the maint, the problem only surfaces at cluster open> time, so if dataset 
> opens at your shop are only sporadic, and not done> all at once, you may not 
> be seeing the problem. On our development> systems, where some of our online 
> regions are bounced all the time, we> have 7000+ datasets registered in RLS, 
> and my performance guy was> sitting on my doorstep the day after the fixes 
> went on DEV, when he was> seeing SMSVSAM go from less than 10 MIPS to over 
> 250 MIPS sustained> bursts. IBM has found the source of the CPU sucking, it 
> is when they> scan the "table" for a dataset name match in the lock 
> structure. The> IBM TEST group load tests in the lab with only 1000 datasets, 
> and that> is why they didn't see the CPU jump I am being told.> > Dave> > 
> _> 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 Mark Zelden> Sent: Tuesday, 
> January 13, 2009 10:18 AM> To: IBM-MAIN@bama.ua.edu> Subject: Re: z/OS 1.10 
> upgrade stopped by RLS - SMSVSAM bug> > I don't think that is true. But 
> perhaps not many are ready to roll 1.10> to production yet. We are a big RLS 
> shop but just starting 1.10 now. > We usually order in Dec. or Jan. after it 
> has been out a while so > shops like yours can work out the bugs for us. :-) 
> > > Actually, SMSVSAM has been behaving fairly well since post z/OS 1.3. Or> 
> at least the end of our z/OS 1.3 after many many PTFs were applied. > We had 
> problems all the time back then. > > Please keep us posted!> > 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
--
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: Query on SUB-CAPACITY PLANNING TOOL data

[Hal Merritt]

That does not look like the IBM planning report. The LPAR name is missing, so 
it could be that you are seeing a line for each LPAR. There is a R4A calculated 
for each LPAR and another (a vector sum) calculated for billing.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Tommy Tsui
Sent: Tuesday, January 13, 2009 3:29 AM
To: IBM-MAIN@bama.ua.edu
Subject: Query on SUB-CAPACITY PLANNING TOOL data

hi all,

After I ran the SCPT, I found many duplicate time record with
different R4 value. Is there something wrong on SCPT report?

"Date-Time of RMF
Datetime R4 for lpar
"30 Nov 08 - 06:05", 15
"30 Nov 08 - 06:10", 18
"30 Nov 08 - 06:10", 28
"30 Nov 08 - 06:15", 11
"30 Nov 08 - 06:20", 33
"30 Nov 08 - 06:20", 21

Thanks and regards

--
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
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

--
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: AIX gets 64 bit COBOL but still none for Z/os ...

[Ed Gould]

--- On Fri, 1/9/09, R.S.  wrote:

> From: R.S. 
> Subject: Re: AIX gets 64 bit COBOL but still none for Z/os ...
> To: IBM-MAIN@bama.ua.edu
> Date: Friday, January 9, 2009, 7:56 AM
> Is there any reason to have 64-bit
> COBOL on z/OS ?
> Of course except satisfaction when watching AMODE 64 in
> ISPF member list...
> 
> -- Radoslaw Skorupka
> Lodz, Poland


Radoslaw:

Yes there is. Just last month the *OLD* table problem popped up. User needs 
LARGE in storage table (10G). Her only option was to write the file to a VSAM 
data set and do inquiries on it with I/O. The run time (even with CI's in 
memory) was about 4 hours. She did a rough quicky assembler and it was less 
that 10 minutes (elapsed on both numbers). Now, you tell me it isn't needed. 
This issue has rose time and time again. The answer is always to write an 
assembler program to do it. The *OLD* write it to VSAM option is really 
inexcusable, IMO. Assembler is dead (or at least almost extinct).





  

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

VSM Changes in z/OS 1.10: Beta Systems Software

[Mark Zelden]

FYI - this note just came to me:
==

Dear Users 

Beta Systems Product management has asked us to forward to you an urgent 
message concerning the compatibility of our standard products with IBM's 
z/OS 1.10. 

Please forward this information to your customers, if there is the need 
to do so. 

"Compatibility tests carried out on IBM operating system z/OS 1.10 have 
revealed massive incompatibility between this system and our products. 
This incompatibility was caused by changes to z/OS 1.10. The erroneous 
effects of these changes were fixed by PTF UK42299 from IBM on 24.12.2008. 
Unless IBM PTF UK42299 is implemented correctly, running any of the 
current releases of Beta Systems products under z/OS 1.10 would inevitably 
result in production failures, inconsistencies, and possible loss of data. 

Therefore we must stress that absolutely  n o n e  of the previous software 
releases of our products have been released for operation with z/OS 1.10! 

At Beta systems we are currently developing and testing PTF packages for 
all product releases that are based on BSA Version 4. These PTF packages 
will ensure that z/OS 1.10 is supported. 

The PTF packages will be available from February 2009. 

If you have any questions, please do not hesitate to contact us: 
mailto:d...@betasystems.com 



Technical Background: 
 

# 
HIPER FIX 
# 

Affected: 
- All Beta Systems software products (BSA versions 3 and 4) under z/OS 1.10 

Error: 
- ABEND0C4 in the initialization phase of some products   
- Inconsistencies in the BQL database (subsequent error) 
- Possible data loss !!! 

Temporary status: 
- BSA-based Beta Systems products must not be used with z/OS 1.10 

Fix: 
- PTF package for all the named releases (see below) 
- Fix included in all the new releases (from 1.1.2009) 

Explanation: 
In z/OS 1.10, a far-reaching change was made to the Virtual Storage Manager 
(VSM). This change revealed an error in the C-Start routine (EDCXSTRT), 
which is always used by System-Programmer-C (SPC) programs for initialization. 
The error was caused when storage requested by a C program as "NULL" (global 
variable/pointer) was not initialized. This uninitialized storage led to 
unpredictable errors/abends. 

IBM has described the change to VSM in APAR OA27291(status: open/hiper). 
The error in the SPC start routine EDCXSTRT is described in APAR PK76106. 
PTF UK42299 for APAR PK76106 has been available from IBM since 24.12.2008. 

It is recommended that you apply IBM PTF UK42299 if you are using your own 
SPC programs. PTF UK42299 does not need to be installed for the Beta Systems 
product fix. The PTFs from Beta Systems must be installed before the Beta 
Systems programs affected by this error can run under z/OS 1.10. They will 
not be compatible without the Beta Systems PTFs. Simply installing IBM PTF 
UK42299 will not enable our products to run correctly. 

The following is a list of the affected products and their release levels 
that will support z/OS 1.10 in future: 

Product Supported versions 
BSA V4.2V4.1 
B23 V4.2V4.1 
Beta 48 V4.3*   V4.2 
Beta 88 V4.5*   V4.4V4.3 
Beta 89 V3.4** 
Beta 91 V4.3V4.2 
Beta 92 V4.3V4.2 
Beta 93 V4.2*   V4.1 
Beta 93 - Fast RetrievalV4.1 
Beta 93 - Document Transformer  V4.1 

* z/OS 1.10 support included in the release - no PTFs 
  necessary 
** Only runs under BSA V3.4 level 0234-05 

These PTF packages will be available on the Beta Systems ftp server from
February 2009. 
As usual, you will find the packages in folders with "descriptive" names, 
for example, ftp://ftp.betasystems.com/pub/BETA92/V4R3/cumptfs/   " 

--
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: AIX gets 64 bit COBOL but still none for Z/os ...

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ed Gould
Sent: Tuesday, January 13, 2009 11:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: AIX gets 64 bit COBOL but still none for Z/os ...


 Assembler is dead (or at least almost extinct).



So's COBOL, FORTRAN, and the Mainframe.

Regards,
Steve Thompson
Still programming in ALC after all these years.

-- Opinions expressed by this poster may not be the opinions of poster's
employer. --

--
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: AIX gets 64 bit COBOL but still none for Z/os ...

[John McKown]

On Tue, 13 Jan 2009 09:02:03 -0800, Ed Gould  wrote:

>Yes there is. Just last month the *OLD* table problem popped up. User needs
>LARGE in storage table (10G). Her only option was to write the file to a
VSAM data >set and do inquiries on it with I/O. The run time (even with CI's
in memory) was >about 4 hours. She did a rough quicky assembler and it was
less that 10 minutes >(elapsed on both numbers). Now, you tell me it isn't
needed. This issue has rose >time and time again. The answer is always to
write an assembler program to do it. >The *OLD* write it to VSAM option is
really inexcusable, IMO. Assembler is dead >(or at least almost extinct).

Ed,

Finally! Somebody has actually posted a real case where AMODE(64) would have
solved a problem in a good way. I was also questioning the real need for
this, at least at present. I assume that this table was READ-ONLY and
accessed with a binary search. I have done this for data in AMODE(31)  in
assembler (well, I didn't design it, I just inherited from something written
by another programmer long ago, in a galaxy far, far way - but who programs
in a Ford anyway?).

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

Changman file management on z/OS

[Andy Murawski]

IBM-Main, 
 
I am interested in how other shops running Serenas Changeman are managing 
the Changeman files or exceptions if any and why. 

1. Any issues with PDSE's vs PDS's? 

2. Excluding any or all files from GRS, MIM? 

3. Segregating Changeman files into their own, isolated storage pool? or 
integrate in the shared storage pools? 

4. Any special space management considerations for some or all Changeman 
files?  Exclude from HSM migratrion, space release?
   
You responses are appreciated, Thanks. 

--
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: vsnprintf(); off by 1!?

[Henry Willard]

Paul Gilmartin wrote:

> On Mon, 12 Jan 2009 22:31:50 -0800, Henry Willard wrote:
> >
> >"memcpy( &ap, &xp, sizeof( va_list ) );" is not legal C. Either use the
> >c99 va_copy ("va_copy(ap,xp)") created for this purpose or define
> >_VARARG_EXT before including stdarg.h. Up until c99 there was no defined
> >way to do what you were trying to do although your method as well as
> >direct assignment worked on many but not all systems.
> >
> Thanks for educating me.  Hmmm...
>
> #define _VARARG_EXT_
>
> leads to:
>
> Trying vsnprintf();
> CEE3204S The system detected a protection exception (System Completion 
> Code=0C4).
>  From entry point f2 at compile unit offset +01A4 at entry offset 
> +01A4 at address 448CCADC.
> [1] + Done(139) gmake varg && ./varg
>   67109204  Segmentation violation  ./varg
>
> ... a step backward.  If vsnprintf() is incompatible with _VARARG_EXT_,
> it would be a courtesy to the programmer to manifest this at compile
> time, possibly by using char** instead of va_list to expose the
> incompatibility.

vsnprintf() is incompatible with C89. Although it has shown up in many 
compilers it was officially introduced to C in C99. You are trying to use two 
features of the C
language that are defined only in C99.

>
>
> I see that va_copy() is defined as:
>
>   #define va_copy(dest, src) ((dest) = (src))
>
> ... simple enough.  But our systems programmer hasn't configured
> the c99 environment.

Then I think you have a complaint with your systems programmer if you want to 
use C99 features.

>
>
> If I undefine and redefine va_start, adding a call to va_arg at
> the end, it works OK.  But my real goal is to get it working in
> enhanced ASCII mode.  And that fails with:
>
> c89 -I.. -D_ALL_SOURCE   -Wa,"ASA,RENT" -Wl,xplink,EDIT=NO -Wc,dll,ascii   -o 
> varg ../source/varg.c /usr/lib/Xaw.x /usr/lib/SM.x /usr/lib/ICE.x 
> /usr/lib/X11.x -lcurses
> -sh 0 + ./varg
> -sh 0 + 2<& 1
> -sh 0 + iconv -f ISO8859-1 -t IBM-1047
> CEE3204S The system detected a protection exception (System Completion 
> Code=0C4).
>  From entry point f2 at compile unit offset +0060 at entry offset 
> +0060 at address 448F0190.
> Format: " %s -- %s "

Your program using either C99 va_copy or _VARARG_EXT and your technically 
illegal memcpy technique works fine for me in enhanced ASCII mode if I tell the 
compiler to use
C99 rules.

>
>
> Thanks,
> gil
>

h

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

Assembler is *NOT* dead! [was: RE: AIX gets 64 bit COBOL ...]

[Farley, Peter x23353]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Ed Gould
> Sent: Tuesday, January 13, 2009 12:02 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: AIX gets 64 bit COBOL but still none for Z/os ...
 
> Assembler is dead (or at least almost extinct).

Hey Ed, watch who you're calling extinct!  There are still a few
Assembler dinos out here who are still very much alive and very much
kicking!

And we're *not* all system programmers, either.  :)

Peter


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


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

Re: Assembler is *NOT* dead! [was: RE: AIX gets 64 bit COBOL ...]

[Rick Fochtman]

I resemble being called "Extinct", under any title. There's still a 
place for us"Dinos" who prize nice tight code that accomplishes the 
required purpose. :-)


Farley, Peter x23353 wrote:


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ed Gould
Sent: Tuesday, January 13, 2009 12:02 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: AIX gets 64 bit COBOL but still none for Z/os ...
   

 
 


Assembler is dead (or at least almost extinct).
   



Hey Ed, watch who you're calling extinct!  There are still a few
Assembler dinos out here who are still very much alive and very much
kicking!

And we're *not* all system programmers, either.  :)

Peter


This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of the 
message is not the intended recipient or an authorized representative of the

intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.


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

 



--
Rick
--
Remember that if you're not the lead dog, the view never changes.



--
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: Assembler is *NOT* dead! [was: RE: AIX gets 64 bit COBOL ...]

[Ed Gould]

SNIP--
> I resemble being called "Extinct",
> under any title. There's still a 
> place for us"Dinos" who prize nice tight code that
> accomplishes the 
> required purpose. :-)
> 
> Farley, Peter x23353 wrote:
> 
> >>

---SNIP-

OK I mis-spoke the idea I was trying to get across was that fewer and fewer 
people know assembler and that its a shame that you need to know it to get pass 
the cobol issue. I do not know if C++ would do it or for that matter any other 
language that is callable with COBOL. It is just a shame that you have to know 
any other language just to do simple table lookups. COBOL was meant to be a 
reasonably simple language (for the masses if you must). 

COBOL if it remains static like it has for many years will need to be replaced 
if it cannot do simple large table lookups. Now if there was some way a service 
was designed for say LE to create large tables and then look items up that 
would be acceptable (I would think). But as one other mentioned there are other 
items that need large amounts of tables as well.
Why not just offer it.


 


  

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

Re: Assembler is *NOT* dead! [was: RE: AIX gets 64 bit COBOL ...]

[John McKown]

On Tue, 13 Jan 2009 12:53:28 -0600, Rick Fochtman  wrote:

>I resemble being called "Extinct", under any title. There's still a
>place for us"Dinos" who prize nice tight code that accomplishes the
>required purpose. :-)
>

Which is better, "nice tight code which accomplishes the required purpose"
or "adequate code which is more easily maintained"? Too bad that neither
choice is available (except maybe on the "z" and "i"). Our choice (here)
seems to be "code which doesn't take the server down too often and reboots
quickly."

--
John

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

TS7700 Historical data (BVIR)

[Steve McCulloch]

Has anyone created a SAS macro that maps out the Historical data from the 
TS7700 BVIR tool? Barry Merril has created one for MXG. However, this is to 
support non-MXG client site and would be used for customized reporting.

Best regards,

Steve McCulloch

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

VTAM security issue

[Itschak Mugzach]

Please have a look at this scenario:

CICS of organization "A" is connected (LU6.2 Connection) to CICS of
organization "B". No problem with that. I looked into the CDRM and found
some other application of organization "B" defined in VTAMLST of oranization
"A". Tried LOGON APPLID(xxx) and gpt the GMtran of org. "B" (if it is the
default, I can travel in this CICS...). I also riched TSO logon etc.

Now, I want to block (at) org "b" ability to get to org "a" applications
other then the CICS connection that was agreed between Org "A" and "B". Is
this possible?
I also want to block the ability to enter logon applid command (may be by
userid, even of the solution will require entering userid & password). How
to achive that?
What other alternatives are offered to connect to vtam applications when USS
tab is displaied, other then LOG APPLID and selecting from the uss tab? I
mean, is there any bypass to LOG APPLID if blocked?

Regards,

ITschak

--
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: VSM Changes in z/OS 1.10: Beta Systems Software

[Guy Gardoit]

Hmmm, a vendor who uses the poor programming practice of not initializing
their GETMAIN'ed storage.   You always get bit in the "end" by assuming.

Guy Gardoit
z/OS Systems Programming

On Tue, Jan 13, 2009 at 12:05 PM, Mark Zelden wrote:

> FYI - this note just came to me:
> ==
>
> Dear Users
>
> Beta Systems Product management has asked us to forward to you an urgent
> message concerning the compatibility of our standard products with IBM's
> z/OS 1.10.
>
> Please forward this information to your customers, if there is the need
> to do so.
>
> "Compatibility tests carried out on IBM operating system z/OS 1.10 have
> revealed massive incompatibility between this system and our products.
> This incompatibility was caused by changes to z/OS 1.10. The erroneous
> effects of these changes were fixed by PTF UK42299 from IBM on 24.12.2008.
> Unless IBM PTF UK42299 is implemented correctly, running any of the
> current releases of Beta Systems products under z/OS 1.10 would inevitably
> result in production failures, inconsistencies, and possible loss of data.
>
> Therefore we must stress that absolutely  n o n e  of the previous software
> releases of our products have been released for operation with z/OS 1.10!
>
> At Beta systems we are currently developing and testing PTF packages for
> all product releases that are based on BSA Version 4. These PTF packages
> will ensure that z/OS 1.10 is supported.
>
> The PTF packages will be available from February 2009.
>
> If you have any questions, please do not hesitate to contact us:
> mailto:d...@betasystems.com
>
>
>
> Technical Background:
> 
>
> #
> HIPER FIX
> #
>
> Affected:
> - All Beta Systems software products (BSA versions 3 and 4) under z/OS 1.10
>
> Error:
> - ABEND0C4 in the initialization phase of some products
> - Inconsistencies in the BQL database (subsequent error)
> - Possible data loss !!!
>
> Temporary status:
> - BSA-based Beta Systems products must not be used with z/OS 1.10
>
> Fix:
> - PTF package for all the named releases (see below)
> - Fix included in all the new releases (from 1.1.2009)
>
> Explanation:
> In z/OS 1.10, a far-reaching change was made to the Virtual Storage Manager
> (VSM). This change revealed an error in the C-Start routine (EDCXSTRT),
> which is always used by System-Programmer-C (SPC) programs for
> initialization.
> The error was caused when storage requested by a C program as "NULL"
> (global
> variable/pointer) was not initialized. This uninitialized storage led to
> unpredictable errors/abends.
>
> IBM has described the change to VSM in APAR OA27291(status: open/hiper).
> The error in the SPC start routine EDCXSTRT is described in APAR PK76106.
> PTF UK42299 for APAR PK76106 has been available from IBM since 24.12.2008.
>
> It is recommended that you apply IBM PTF UK42299 if you are using your own
> SPC programs. PTF UK42299 does not need to be installed for the Beta
> Systems
> product fix. The PTFs from Beta Systems must be installed before the Beta
> Systems programs affected by this error can run under z/OS 1.10. They will
> not be compatible without the Beta Systems PTFs. Simply installing IBM PTF
> UK42299 will not enable our products to run correctly.
>
> The following is a list of the affected products and their release levels
> that will support z/OS 1.10 in future:
>
> Product Supported versions
> BSA V4.2V4.1
> B23 V4.2V4.1
> Beta 48 V4.3*   V4.2
> Beta 88 V4.5*   V4.4V4.3
> Beta 89 V3.4**
> Beta 91 V4.3V4.2
> Beta 92 V4.3V4.2
> Beta 93 V4.2*   V4.1
> Beta 93 - Fast RetrievalV4.1
> Beta 93 - Document Transformer  V4.1
>
> * z/OS 1.10 support included in the release - no PTFs
>  necessary
> ** Only runs under BSA V3.4 level 0234-05
>
> These PTF packages will be available on the Beta Systems ftp server from
> February 2009.
> As usual, you will find the packages in folders with "descriptive" names,
> for example, ftp://ftp.betasystems.com/pub/BETA92/V4R3/cumptfs/   "
>
> --
> 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: VSM Changes in z/OS 1.10: Beta Systems Software

[Mark Zelden]

On Tue, 13 Jan 2009 15:02:53 -0500, Guy Gardoit  wrote:

>Hmmm, a vendor who uses the poor programming practice of not initializing
>their GETMAIN'ed storage.   You always get bit in the "end" by assuming.
>
>Guy Gardoit
>z/OS Systems Programming

If you are referring to the EDCXSTRT error, this was an IBM problem
described by APAR PK76106.   Although it's not clear why  "Simply 
installing IBM PTF UK42299 will not enable our [Beta] products to run
correctly."  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: VTAM security issue

[Chris Mason]

Itschak

I'm afraid you'll need to clarify rather a lot here!

A CICS application in session with another CICS application is one thing. A 
session initiated by means of Unformatted System Services (USS) is quite 
another.

Your CICS-CICS session is LU type 6.2. Any session initiated with the aid of 
USS will never be LU type 6.2. It is very likely to be LU type 2 or - unlikely 
- 
LU type 1 or, if using pre/non-SNA channel-attached 3270 or 3270 look-alike, 
LU type 0 with a 3270 data stream.[1]

So we can ignore your mentioning the CICS-CICS session as irrelevant.

I have no idea what you might mean by "looking into the CDRM". Please explain.

You will find the names of cross-domain LUs which may be application LUs in 
CDRSC major nodes. Normally today - since the early '80s - same-network 
CDRSCs will be allowed to be defined dynamically. Of course, inertia lasting 
nearly 3 decades now may have allowed such definitions still to exist. Again a 
bit of clarification and possibly correction is needed here.

"GMtran" is the term using for the CICS "Good Morning" message I believe. If 
you get this you must have logged onto CICS so I'm not sure why you are 
talking about other cross-domain applications.

You had better explain how you knew how to log onto the other, cross-
domain, TSO. You need only explain where you found the name to use in the 
LOGON APPLID(the-other-tso).

You should make sure you are not talking about session monitor applications. 
If you can log onto a session monitor application on the other, cross-domain, 
system, you will be able to access whatever is presented - but normally 
access can require a userid and password.

You seem to be confused by USS. USS traffic happens only same-domain. It 
operates over the SSCP-LU session which is, by definition, same-domain. Or 
maybe I'm just confused by the way you have expressed yourself.

If you want to prevent some combinations of session, you can do so by means 
of the session management exit.

Alternatively, you can discard all the nice dynamic capabilities for which VTAM 
customers cried out in agony at having to create so many definitions all those 
years ago and forbid the dynamic creation of CDRSCs.[2] You can define 
CDRSCs in both systems for the other CICS system so that only that session 
can be established cross-domain. I now see - I think - why you mentioned the 
CICS-CICS session.

I think I may finally have fought my way through the obfuscations to that to 
which what you are really driving. Have I?

Incidentally, back in the early '80s, I recall my colleagues and I trying to 
work 
out whether or not use of LOGON APPLID could be prevented by some 
particular coding of the USS table. It can't!

Chris Mason

[1] There are others historically but very, very unlikely today.

[2] Post again if you need help with this. Essentially, it's in the definition 
of 
the CDRM statements.

On Tue, 13 Jan 2009 21:33:35 +0200, Itschak Mugzach 
 wrote:

>Please have a look at this scenario:
>
>CICS of organization "A" is connected (LU6.2 Connection) to CICS of
>organization "B". No problem with that. I looked into the CDRM and found
>some other application of organization "B" defined in VTAMLST of oranization
>"A". Tried LOGON APPLID(xxx) and gpt the GMtran of org. "B" (if it is the
>default, I can travel in this CICS...). I also riched TSO logon etc.
>
>Now, I want to block (at) org "b" ability to get to org "a" applications
>other then the CICS connection that was agreed between Org "A" and "B". Is
>this possible?
>I also want to block the ability to enter logon applid command (may be by
>userid, even of the solution will require entering userid & password). How
>to achive that?
>What other alternatives are offered to connect to vtam applications when 
USS
>tab is displaied, other then LOG APPLID and selecting from the uss tab? I
>mean, is there any bypass to LOG APPLID if blocked?
>
>Regards,
>
>ITschak

--
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: VSM Changes in z/OS 1.10: Beta Systems Software

[Jim Mulder]

IBM Mainframe Discussion List  wrote on 01/13/2009 
03:14:09 PM:

> 
> If you are referring to the EDCXSTRT error, this was an IBM problem
> described by APAR PK76106.   Although it's not clear why  "Simply 
> installing IBM PTF UK42299 will not enable our [Beta] products to run
> correctly." 

  The IBM code fixed by PTF UK42299 is linked into and thus distributed
with the ISV product.

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
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: VSM Changes in z/OS 1.10: Beta Systems Software

[Mark Zelden]

On Tue, 13 Jan 2009 16:17:43 -0500, Jim Mulder  wrote:

>IBM Mainframe Discussion List  wrote on 01/13/2009
>03:14:09 PM:
>
>>
>> If you are referring to the EDCXSTRT error, this was an IBM problem
>> described by APAR PK76106.   Although it's not clear why  "Simply
>> installing IBM PTF UK42299 will not enable our [Beta] products to run
>> correctly."
>
>  The IBM code fixed by PTF UK42299 is linked into and thus distributed
>with the ISV product.
>

Thanks Jim.  I figured that was the answer, but wasn't sure based on reading
the APAR and my lack of knowledge in this area and knowing that LE fixes
are generally just "run time".

I know you don't do LE, but under "RECOMMENDATION:" in the APAR it
should say something like:  "Install the PTF for APAR PK76106 and relink
the application.".  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: vsnprintf(); off by 1!?

[Thomas David Rivers]

Paul Gilmartin wrote:

Are questions about C better asked here or on MVS-OE?  Surely
not on ASSEMBLER_LIST -- it's far too busy this week with a
nostalgia thread.

The C test program:


Do I fail to understand something, or have I (again)
encountered a bug?  I'll welcome any workaround that
doesn't break compatibility with the other 2 systems.
I'll likewise welcome a test on another system (Linux?)

Thanks,
gil



Just to provide another data point, the example
program generated this with Dignus Systems/C:

Format: " %s -- %s "
First : "foo"
Second: "bar"

Retrying
First : "foo"
Second: "bar"

Trying vsnprintf();
 foo -- bar



The Dignus va_copy() macro is defined thusly:

#define va_copy(dest, src) \
((dest) = (va_list)(src))

and is present regardless of any particular setting
(C99 or otherwise.)

This link:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

is a copy of a late draft of the C99 standard (it's not too
far off... you have to, unfortunately, pay $$$ for the standard,
and are not allowed to distribute it.. or - I'd post
something more precise.)

But - as has been mentioned, va_copy() is part of the C99
standard... technically, providing it regardless of the environment
may violate the C89 standard (since, I think it might invade
the C89 namespace - would have to check the C89 standard to
be sure.. C89 may have reserved va_copy())... but, as this is common
practice, we go ahead and do it.

- Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.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: AIX gets 64 bit COBOL but still none for Z/os ...

[Thomas David Rivers]

Ed Gould wrote:

--- On Fri, 1/9/09, R.S.  wrote:



From: R.S. 
Subject: Re: AIX gets 64 bit COBOL but still none for Z/os ...
To: IBM-MAIN@bama.ua.edu
Date: Friday, January 9, 2009, 7:56 AM
Is there any reason to have 64-bit
COBOL on z/OS ?
Of course except satisfaction when watching AMODE 64 in
ISPF member list...

-- Radoslaw Skorupka
Lodz, Poland




Radoslaw:


 The answer is always to write an assembler program to do it.



  


Just to add a quick note to that, a popular option
for our users is to write a quick-n-dirty C function
to handle the 64-bit data (directly callable from 31-bit
COBOL).

I'm just suggesting an alternative to an assembly program
that our users have found helpful.

- Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.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: AIX gets 64 bit COBOL but still none for Z/os ...

[John McKown]

On Tue, 13 Jan 2009 16:52:07 -0500, Thomas David Rivers 
wrote:

>Ed Gould wrote:
>> --- On Fri, 1/9/09, R.S.  wrote:
>>
>>
>>>From: R.S. 
>>>Subject: Re: AIX gets 64 bit COBOL but still none for Z/os ...
>>>To: IBM-MAIN@bama.ua.edu
>>>Date: Friday, January 9, 2009, 7:56 AM
>>>Is there any reason to have 64-bit
>>>COBOL on z/OS ?
>>>Of course except satisfaction when watching AMODE 64 in
>>>ISPF member list...
>>>
>>>-- Radoslaw Skorupka
>>>Lodz, Poland
>>
>>
>>
>> Radoslaw:
>
>  The answer is always to write an assembler program to do it.

But there are fewer and fewer HLASM programmers. And I'd bet most companies
want to discontinue it entirely because COBOL is more maintainable by the
normal programming staff (no questions about the abnormal programming staff,
please!).

>
>Just to add a quick note to that, a popular option
>for our users is to write a quick-n-dirty C function
>to handle the 64-bit data (directly callable from 31-bit
>COBOL).

Requires a C compiler. And that costs more money. Not cost effective if the
only use is to access 64 bit memory from COBOL.

>
>I'm just suggesting an alternative to an assembly program
>that our users have found helpful.
>
>   - Dave Rivers -

--
John

--
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: VTAM security issue

[Tony Harminc]

2009/1/13 Itschak Mugzach 
>
> Please have a look at this scenario:
>
> CICS of organization "A" is connected (LU6.2 Connection) to CICS of
> organization "B". No problem with that. I looked into the CDRM and found
> some other application of organization "B" defined in VTAMLST of oranization
> "A". Tried LOGON APPLID(xxx) and gpt the GMtran of org. "B" (if it is the
> default, I can travel in this CICS...). I also riched TSO logon etc.
>
> Now, I want to block (at) org "b" ability to get to org "a" applications
> other then the CICS connection that was agreed between Org "A" and "B". Is
> this possible?

Sure, but you have to code up a VTAM Session Management Exit (SME).
This is described in the SNA Customization book. The summary says "The
session management exit is a multi-function exit that you can use to
control and manage LU-LU session-related functions. You can use the
exit to authorize session establishments, obtain session accounting
data, and better manage SSCP and GWPATH selection."

Coding a basic SME is not too difficult, but getting it to do what you
want flexibly is a little harder. You could just hard code the
sessions to be allowed, or those to be denied, but then if somone
changes the naming conventions, you have a problem.

There is at least one commercial product, Blockade For MVS, which has
been around for a long time (since 1988), that manages and authorizes
SNA sessions in a very flexible way based on RACF permissions, and
also provides management of 3270 logons via a session manager. This
was developed by Blockade, was acquired by Proginet in 2005, and has
recently been acquired by Beta Systems Software. I guess I should
mention that I work there...

> I also want to block the ability to enter logon applid command (may be by
> userid, even of the solution will require entering userid & password). How
> to achive that?

I doubt you can do that with USS, but I may be wrong. But there is
nothing to say you have to provide a USS screen to your users.

> What other alternatives are offered to connect to vtam applications when USS
> tab is displaied, other then LOG APPLID and selecting from the uss tab? I
> mean, is there any bypass to LOG APPLID if blocked?

Um, Blockade For MVS can help with that too.

Having mentioned this product, since I'm in development, not
marketing, I should say that I'm not sure if it is being actively
marketed any more. Certainly it is still fully supported, and running
happily at a number of customer sites, but controlling SNA connections
is nowadays a "legacy" niche. But if it's what you need, it works very
well.

Tony H.

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

Why MS is winning the battle

[Ed Gould]

http://boycottnovell.com/2009/01/10/edgi-continued-dumping-vs-gnu/

How Microsoft Beats GNU/Linux In Schools
from the doing-battle-like-an-insider dept.



  

--
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 to interrupt an LPAR ?

[John Eells]

Chris Mason wrote:
Causing an "external interrupt" to be presented to the software, the operating 
system's interrupt handling logic, running in an LPAR - logically behaving as an 
individual processor - looks entirely logical and sensible to me.



Just so everyone knows...the external interrupt's sole action in z/OS R8 
and later is to issued the message: "IEA035I EXTERNAL INTERRUPT KEY IS 
NO LONGER SUPPORTED."


(The older messages remain in the current book for those using an 
uplevel book to look at message explanations for downlevel systems.)


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

another IBM meaning for NIP

[Steele, Phil]

 

 

 

-Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Hal Merritt
> Sent: Wednesday, 14 January 2009 3:15 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: NIP console devices limit

 

 

I'm sorry I can't help myself!

Many years ago, we had a quite a bit of Series/1 equipment, which was
largely customer set up. 

Once I needed to move an  attachment card from one cpu to another. As
was their want, IBM charged a (nominal) fee to amend their records as to
what feature was on what machine. ( remember, the customer himself [me
in this case] actually performed this movement). 

 We later got an invoice from IBM which  said something like
"reinstallation(N.I.P) of xyz attachment card"  I assumed that NIP stood
for some thing like "Now Installed Part/Product"  or similar.  I was
later informed that no, NIP in fact stood for "Non Ibm Person" ( i.e.
me, in this case). That, I thought, put me in my place!.

 

Phil Steele ( still a N.I.P, but I know quite a few others... I am not
alone in this regard) 


***
The information in this e-mail message and any files transmitted with it are 
intended to be confidential and for the use of only the individual or entity to 
whom they are addressed. The message and files may be protected by legal 
professional privilege, or other legal rules. The confidentiality of and 
privilege applying to this message and files is not waived if this message or 
files has been sent to you by mistake. If the reader of this message or files 
is not the intended recipient, you are notified that retention, distribution or 
copying of this message and files are strictly prohibited.  If you receive this 
message or files in error, please notify us immediately by telephone or return 
e-mail and delete all copies from your computer system. It is the recipient's 
responsibility to check this message and files for viruses.
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: How to interrupt an LPAR ?

[Jim Mulder]

John Eells/Poughkeepsie/i...@ibmus wrote on 01/13/2009 09:45:57 PM:
 
> Just so everyone knows...the external interrupt's sole action in z/OS R8
> and later is to issued the message: "IEA035I EXTERNAL INTERRUPT KEY IS
> NO LONGER SUPPORTED."

  The z/OS Standalone-dump program continues to treat an interrupt-key
external interrupt as a request by the operator to prematurely 
terminate the dump. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
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: VSM Changes in z/OS 1.10: Beta Systems Software

[Barbara Nitz]

>> The IBM code fixed by PTF UK42299 is linked into and thus distributed
>>with the ISV product.

>Thanks Jim. I figured that was the answer, but wasn't sure based on reading
>the APAR and my lack of knowledge in this area and knowing that LE fixes
>are generally just "run time".

>I know you don't do LE, but under "RECOMMENDATION:" in the APAR it
>should say something like: "Install the PTF for APAR PK76106 and relink
>the application.". 

Actually, I found the text of the Beta flash rather confusing, so I called 
someone in Beta (not the hotline) and was told:

1. Beta Systems found it very hard to get IBM to acknowledge that the bug was 
in that EDCXSTRT lmod.
:-) 

2. As Jim already indicated, they need to relink their applications with that 
lmod to pick up the fix and distribute that. (As an aside, let's hope they 
catch all of them - I had a case where they didn't know where they used a 
csect, to the effect that I hit the same bug in three different areas, one 
after the other. Got five fixes in all. In another case they gave me a ptf for 
a product based on another ptf in the BSA which of course did not have any 
SMP/E dependency.) Also, I was told that the first fixes (for BSA and Beta92) 
will be available at the beginning of next week. Check their website/hotline.

3. Beta Systems said that they have been using C (or C+ or C++ or something)  
for *years* *without* the need for LE. And I thought *that* was only available 
as MetalC starting with 1.10.

Best regards, Barbara Nitz

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger

--
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: AIX gets 64 bit COBOL but still none for Z/os ...

[Ed Gould]

Yes thanks bit as others have mentions C isn't licensed at the installation and 
the number of COBOL programmers who do know c is less than the number of 
Assembler  types out there. I have found that the senior COBOL types have over 
the years have picked up assembler (little bits) as it is needed for real 
debugging at times.

Ed


--- On Tue, 1/13/09, Thomas David Rivers  wrote:
--SNIP--
> Just to add a quick note to that, a popular option
> for our users is to write a quick-n-dirty C function
> to handle the 64-bit data (directly callable from 31-bit
> COBOL).
> 
> I'm just suggesting an alternative to an assembly program
> that our users have found helpful.
> 
>     - Dave Rivers -
> 
> -- 
> riv...@dignus.com 
>                
--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: VTAM security issue

[Itschak Mugzach]

Chris,

I know all this, but I think that at the end of your answer you started to
understand. Org. "A" and org "B" are partners that security shares CICS
resources VIA a CICS connection. When defining the connection, you can limit
who can use which trx (by identifying the user or by assigning a user to the
connection and protect the transactions).
Now, there is no way to stop some one in org "A" to simply logon to org "B"
CICS. Believe me, I tried it and accessed many vtam applications. few of
them where no protected well. Some of them uses default ACB names. the
ability to finally logon into is depend on the level of security implemented
at org "B". In many cases I tested, it was not a problem to enter in. I am
sure I can do it with some success at any site. There are always holes in
security.

I started my research at the CDRSC (what i called cross domain "CDRM") and
found few CICS systems (including the one which is connected to the local
CICS). Luckily, some of them where not up...

Now that I found the door, I am looking to see how to limit Access from A to
B by LU 6.2 from CICS and not from any terminal at "A". I think that the two
organization agrred to connect their CICS systems on a limited services. Not
to open a door to any terminal and to any vtam application. Assume that LOG
APPL will accept netname.applid as P1...

Regards,

ITschak




On Tue, Jan 13, 2009 at 10:43 PM, Chris Mason wrote:

> Itschak
>
> I'm afraid you'll need to clarify rather a lot here!
>
> A CICS application in session with another CICS application is one thing. A
> session initiated by means of Unformatted System Services (USS) is quite
> another.
>
> Your CICS-CICS session is LU type 6.2. Any session initiated with the aid
> of
> USS will never be LU type 6.2. It is very likely to be LU type 2 or -
> unlikely -
> LU type 1 or, if using pre/non-SNA channel-attached 3270 or 3270
> look-alike,
> LU type 0 with a 3270 data stream.[1]
>
> So we can ignore your mentioning the CICS-CICS session as irrelevant.
>
> I have no idea what you might mean by "looking into the CDRM". Please
> explain.
>
> You will find the names of cross-domain LUs which may be application LUs in
> CDRSC major nodes. Normally today - since the early '80s - same-network
> CDRSCs will be allowed to be defined dynamically. Of course, inertia
> lasting
> nearly 3 decades now may have allowed such definitions still to exist.
> Again a
> bit of clarification and possibly correction is needed here.
>
> "GMtran" is the term using for the CICS "Good Morning" message I believe.
> If
> you get this you must have logged onto CICS so I'm not sure why you are
> talking about other cross-domain applications.
>
> You had better explain how you knew how to log onto the other, cross-
> domain, TSO. You need only explain where you found the name to use in the
> LOGON APPLID(the-other-tso).
>
> You should make sure you are not talking about session monitor
> applications.
> If you can log onto a session monitor application on the other,
> cross-domain,
> system, you will be able to access whatever is presented - but normally
> access can require a userid and password.
>
> You seem to be confused by USS. USS traffic happens only same-domain. It
> operates over the SSCP-LU session which is, by definition, same-domain. Or
> maybe I'm just confused by the way you have expressed yourself.
>
> If you want to prevent some combinations of session, you can do so by means
> of the session management exit.
>
> Alternatively, you can discard all the nice dynamic capabilities for which
> VTAM
> customers cried out in agony at having to create so many definitions all
> those
> years ago and forbid the dynamic creation of CDRSCs.[2] You can define
> CDRSCs in both systems for the other CICS system so that only that session
> can be established cross-domain. I now see - I think - why you mentioned
> the
> CICS-CICS session.
>
> I think I may finally have fought my way through the obfuscations to that
> to
> which what you are really driving. Have I?
>
> Incidentally, back in the early '80s, I recall my colleagues and I trying
> to work
> out whether or not use of LOGON APPLID could be prevented by some
> particular coding of the USS table. It can't!
>
> Chris Mason
>
> [1] There are others historically but very, very unlikely today.
>
> [2] Post again if you need help with this. Essentially, it's in the
> definition of
> the CDRM statements.
>
> On Tue, 13 Jan 2009 21:33:35 +0200, Itschak Mugzach
>  wrote:
>
> >Please have a look at this scenario:
> >
> >CICS of organization "A" is connected (LU6.2 Connection) to CICS of
> >organization "B". No problem with that. I looked into the CDRM and found
> >some other application of organization "B" defined in VTAMLST of
> oranization
> >"A". Tried LOGON APPLID(xxx) and gpt the GMtran of org. "B" (if it is the
> >default, I can travel in this CICS...). I also riched TSO logon etc.
> >
> >Now, I want to block (at) org "b" ability to get to org "a"

Re: AIX gets 64 bit COBOL but still none for Z/os ...

[Timothy Sipples]

Ed Gould writes:
>Yes there is. Just last month the *OLD* table problem popped up.
>User needs LARGE in storage table (10G). Her only option was to.
>write the file to a VSAM data set and do inquiries on it with
>I/O. The run time (even with CI's in memory) was about 4 hours..
>She did a rough quicky assembler and it was less that 10 minutes
>(elapsed on both numbers).

If you've got CICS, how about using a 64-bit container? This feature is
available starting in CICS Transaction Server Version 3.2 (in 2007), when
containers were moved above the bar. They should be quite transparent to
your 31-bit application. (Just call CICS and let it do the lifting.) It's
hard to say what CPU time you'd see, but my guess is it'd be closer to the
10 minute number for a comparable run.

64-bit C (or C++) is another option, as pointed out. No, it's not that
expensive. There are at least 3 commercial compilers available.),

64-bit Java is a possible option. Java is a standard z/OS feature (no
additional license charge) and zAAP eligible. (Can Enterprise COBOL's
INVOKE statement call 64-bit Java? I'll have to check that.)

64-bit Assembler is still an option. That's a standard z/OS feature,
too.

Certain other middleware products (besides CICS) may be relevant.
WebSphere Transformation Extender comes to mind as a possibility, for
example.

There are undoubtedly ways to do this (handle 10G) using multiple
address spaces (~6+) that collaborate. Might even be some workload
advantages to that, actually, depending on the situation.

All that said, please get your requirements for 64-bit COBOL into IBM. (And
PL/I, for that matter.) IBM is listening. The more information you can
provide about your situation, both technical and non-technical, the better.
Yes, as alluded to previously in this thread, LE is very much a technical
factor here. Any path (how, and thus partly when) to 64-bit is
customer-driven, not religious or political.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Based in Tokyo, Serving IBM Japan / Asia-Pacific
E-Mail: timothy.sipp...@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: APF auth question

[Vernooy, C.P. - SPLXM]

 wrote in message
news:
...
> I am trying to learn the things, so excuse the 'funny' question.
> 
> i can issue the command SETPROG APF,ADD,DSNAME=
> to make a PDS/PDSEAPF authorized.
> 
> However, I cannot imagine that it would have effect upon
> the contents of SYS1.PARMLIB(IEAAPFxx).
> 
> Am I correct?
> 
> If I am correct, then the effectiveness of the SETPROG command is
> only until the next IPL,  correct?
> 
> Thanks

Steve,

That is correct (2x).

Kees.

PS: this newsgroup is a mirror of a listserver, where the majority of
the IBM-MAIN population resided. To subscribe to the listserver, see the
information is attached automagically at the bottom.
**
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