Re: IBM Manuals

[Ed Gould]

Scott:

Last year I got an brand new IPAD. The installation instructions were  
on a 3 X 5  in a 4 page "booklet". The font size was 4 and I could  
not read it to save my life. I had to get a friend to come over to  
read them so I could do the "install".

Bah humbug so much APPLE being user friendly.

Ed

On Dec 27, 2011, at 12:56 PM, Scott Ford wrote:

lol, love it I have a19 inch one here at home where I  
work ...Maybe they are telling us old dinosaurs we are getting old,  
man



Scott J Ford
Software Engineer
http://www.identityforge.com




 From: Mike Schwab 
To: IBM-MAIN@bama.ua.edu
Sent: Tuesday, December 27, 2011 1:37 PM
Subject: Re: IBM Manuals

Maybe they think everyone should be using 32 inch 1080P TVs as  
monitors?


On Tue, Dec 27, 2011 at 12:13 PM, Scott Ford  
 wrote:

Lizette:

Thanks, I thought it was these 61 yr old eyes...lol. I zoomed IE9  
up to like 200+ % ..to read the TOC of the manual on the right  
panel of the page...


Scott J Ford
Software Engineer
http://www.identityforge.com

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

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


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

Re: cpu / machine identification

[Ed Gould]

On Dec 26, 2011, at 3:11 PM, zMan wrote:


OK, I gotta ask -- what's the problem you're trying to solve? You
don't trust your customers? In over a quarter century in the mainframe
software business, I've come across ONE customer running software on
an unlicensed box, and it was an oversight -- and a nice full-price
bluebird for the sales rep. I don't believe "CPUIDs" are worth the
hassle.


OK,

I have run into two companies and one was just cheapness and the  
other was well dishonest.
Both knew better but until a hammer is applied at the head nothing  
was accomplished.

I pointed out the issue and was told to shut up.
The other company claimed stupidity and I was told to shut up.
Ed

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

Re: RSU Apply Error in PTF

[Mike Schwab]

https://www-304.ibm.com/support/docview.wss?uid=isg1OA31806

On Thu, Dec 29, 2011 at 11:14 PM, saurabh khandelwal
 wrote:
>>
>>  Hello,
>>                  Currently I am applying RSU1110 on z/Os 1.11 system. I
>> run apply job after apply check job run successfully with RC 00.
>>
>> But in apply job I received RC 08 for some of the PTF. When I looked at
>> output , I found most of the PTF failed because of  UA59434 PTF. In more
>> detail I found below error in my job.
>>
>> CAUSER   FMID     MESSAGE ID  PAGE   ERROR DESCRIPTION AND POSSIBLE CAUSES
>>
>>  UA59434  HJE7760  GIM24001E      8   ASSEMBLER PROCESSING FAILED FOR
>> MODULE ISFDA IN THE SISFSRC1 LIBRARY. THE RETURN
>>                                       CODE WAS 04.
>>                                       --- POSSIBLE CAUSES ---
>>                                       1. THE ASSEMBLER TEXT WAS IN ERROR.
>>                                       2. THE WRONG LEVEL OF MACROS WAS
>> BEING USED.
>>                                       3. THE WRONG SET OF MACLIBS WAS
>> BEING USED.
>>
>> I am really not getting clue to resolve this issue. I am attaching apply
>> job output. Can you please help me to resolve this issue.
>>
>> Regards



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: cpu / machine identification

[Ed Gould]

Sam:

From some experience. We were constantly adding/changing cpu's over  
just a two year period I remember going through at least 15 changes  
and it could have been more. From past experience PLEASE allow some  
amount of time (execution wise) if the serial number(s) do not agree.  
We would get the serial numbers invariably on Friday and have to make  
30-40 (it was spread out over several people) phone calls. INVARIABLY  
a number was either misread or mis-keyed or whatever and we had to  
make emergency phone calls in the middle of the night to the software  
company asking for a temporary number until the morning.
Also please do not keep the keys in storage (or if you do allow a  
simple way to update them).
We had one vendor who will remain nameless who didn't have 24 hour  
support and it was a critical piece of software and we had to back  
out the upgrade what a disaster. Needless to say the vendor got  
kicked out of the shop as soon as we found a replacement.


Ed

On Dec 26, 2011, at 3:19 PM, Sam Siegel wrote:


zMan - Thanks for the reply.  It is a new product - No customers yet.

I would like enough licensing to keep honest people honest and an
operationally oriented reminder for the annual renewal.

Sam

On Mon, Dec 26, 2011 at 1:11 PM, zMan  wrote:


Gahh, "IF BibBox, Inc".

On Mon, Dec 26, 2011 at 4:11 PM, zMan  wrote:

On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel  wrote:
Hello List - I'm attempting to create a licensing mechanism for  
a bit

of software.  I would like to be able to use a unique and
non-modifiable identifier as part of the mechanism.

The CSRSI callable service and STSI instruction provide a  
variety of

hardware related identifiers.

CSRSI returns fields called si00pccacpid and si11v1cpcsequencecode.

 These
appear directly related to PCCACPID (PCCA control block) and  
Sequence

Code

(STSI basic machine configuration)..

Is there any preference to using one field over the other?  What  
are the

advantages and disadvantages of using each field?

Are there other fields (in same or other control blocks) that  
should be

used?

Please feel free to treat this as an open ended question related to
licensing mechanism and provided any related advice and tips  
based on

experience.


OK, I gotta ask -- what's the problem you're trying to solve? You
don't trust your customers? In over a quarter century in the  
mainframe

software business, I've come across ONE customer running software on
an unlicensed box, and it was an oversight -- and a nice full-price
bluebird for the sales rep. I don't believe "CPUIDs" are worth the
hassle.

Having said that, I would expect that any CPUID processing would  
work

off, well, the CPUID. That's what customers understand.

SAS Institute used to have a nice CPUID system for their C compiler
that would issue a warning and print out what company the sucker was
licensed to, but would continue to operate if the CPUID was wrong.
This allowed emergency operation, while clearly keeping any real
company from running it on the wrong box (though I suppose of  
BigBox,

Inc. licensed it on one and ran it on two, it would be harder to
notice; the case I'm thinking of was when we were running the
Merrill-Lynch copy on another company's machine, WITH permission  
from

SAS; every time we invoked the compiler, it would whine and say
"Licensed to Merrill-Lynch").

Now, with systems management stuff that doesn't have a real UI that
gets invoked all the time, it's harder. The best I've seen allowed:
- multiple key entries in the CPUID file, so you didn't have to  
worry

about swapping files at expiration: you just added new entries and
eventually deleted the old ones. And you could keep all your  
CPUIDs in

a common file, shared (or replicated) across systems.
- Warned starting 30 days before expiration, on the operator's
console: "XYZ will expire in 30 days" (29, 28...).
- If it had a valid license (i.e., one with time on it but on the
wrong machine) would run in "emergency mode", whining on the
operator's console every 10 minutes or so, but still running (this
allowed for DR).
- Supported "universal" temporary keys, that could be
read/emailed/FAXed by support at 3AM if you really screwed up and  
were

dead in the water despite the above.

Now, this also meant that there were folks carrying beepers and temp
keys, so they could do that after-hours support.

Are you prepared to deal with all this? Is it worth it?

As you can tell, I'm not a fan of such mechanisms. But it's not my
decision (doh), so I'm trying to help :-)
--
zMan -- "I've got a mainframe and I'm not afraid to use it"




--
zMan -- "I've got a mainframe and I'm not afraid to use it"

- 
-

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



--
For IBM-MAIN subscribe / s

RSU Apply Error in PTF

[saurabh khandelwal]

>
>  Hello,
>  Currently I am applying RSU1110 on z/Os 1.11 system. I
> run apply job after apply check job run successfully with RC 00.
>
> But in apply job I received RC 08 for some of the PTF. When I looked at
> output , I found most of the PTF failed because of  UA59434 PTF. In more
> detail I found below error in my job.
>
> CAUSER   FMID MESSAGE ID  PAGE   ERROR DESCRIPTION AND POSSIBLE CAUSES
>
>  UA59434  HJE7760  GIM24001E  8   ASSEMBLER PROCESSING FAILED FOR
> MODULE ISFDA IN THE SISFSRC1 LIBRARY. THE RETURN
>   CODE WAS 04.
>   --- POSSIBLE CAUSES ---
>   1. THE ASSEMBLER TEXT WAS IN ERROR.
>   2. THE WRONG LEVEL OF MACROS WAS
> BEING USED.
>   3. THE WRONG SET OF MACLIBS WAS
> BEING USED.
>
> I am really not getting clue to resolve this issue. I am attaching apply
> job output. Can you please help me to resolve this issue.
>
> Regards
>
>
>
>

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

Re: cpu / machine identification

[Mike Schwab]

On Thu, Dec 29, 2011 at 9:14 PM, John McKown  wrote:
> On Thu, 2011-12-29 at 20:32 -0600, Brian Westerman wrote:
>> I didn't realize that a employee can bind the site, but I can see where that 
>> might actually be the case.
>>
>> I can imagine what would happen to a site like IBM in Dallas, should
>> Microsoft or Corel say, "we're coming on Tuesday to check every one of
>> your machines".  That would be very interesting.
>>
>> Brian
>>
>
> Reminds me vaguely of an internal auditor who wanted access to the z/OS
> system in order to verify that it was not compromised by Windows
> viruses. Was incensed that z/OS did not have any virus scanning software
> installed. Literally __could not__ understand why a Windows virus
> couldn't infect the mainframe. "software is software" and "a system is a
> system". Didn't understand that the z wasn't Intel compatible. Complete
> IT idiot.
>
> --
> John McKown
> Maranatha! <><

Would some of the macro worms be possible to infect some Linux
products with macros on x86 and x64 and S390x?

Our site was audited (I think by detecting software remotely).  We had
license various numbers of licenses for various versions of some
software products.  A later version of the software got included into
the default install image and was installed on lots more machines than
we had licenses for that version.  Cost our site 7 figures to license
what we had installed.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: cpu / machine identification

[John McKown]

Depends on what they want to do. HIPAA is a big deal in my shop. If they
just want SMF data, I normally run the job to create the dataset for
them and send it to them. No big deal about that. If they want a
"sysprog" level access (which has never happened), well, I'll do what
I'm told. But if it were me, I'd tell them to get a court order, siting
HIPAA. And get lots of legal documents signed by somebody like the
president or other high officer of the company. Maybe even many
somebodies.

On Thu, 2011-12-29 at 20:03 -0600, Brian Westerman wrote:
> I'm sorry Schmuel, normally I agree with your point on things, but I
> really have to disagree here.  It's not like I have no experience with
> other sites, we have hundreds of clients, and I have been to well over
> 80% of them in person, and I can state without much worry that the
> percentages would not be on my side that the far greater percentage
> (approaching 100%) would never agree to giving a vendor access to
> their site to "check up" on them.
> 
> Even when we go to a site as the "IBM" people, they go way out of
> their way to make sure that we stay focused on the problem and don't
> just "look around".  As a "non IBM" vendor, it would be even less
> likely that the client would just open their site to us.
> 
> In this case I hardily agree with the view that the the vendor would
> be told to go pound salt.  Imagine the security issues that would have
> to be dealt with to just give them an ID that has the capability to
> check.  
> 
> Brian

-- 
John McKown
Maranatha! <><

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

Re: cpu / machine identification

[Linda Mooney]

Hi Brian, 



/snip 

I received an email between my last response and this one that said (a lot of 
things, but basically) that many sites (the grater percentage) don't know what 
they pay for their software because a) it's done by another department or their 
boss, or b) they only think about it when they first license the product and 
don't think about the cost involved until they either run low on budget and are 
trying to save some amount or they have a problem that makes them unhappy with 
the product that they are currently paying for. 

Is that true across the board with you people? 
/esnip 



All invoices have to be routed to our Accounts Payable folks to get paid here.  
In good budget times, and at the very last minute usually , the Accounts 
Payable folks would ask the technical contact (the sysprog) if the software was 
still being used and if there were any changes planned.  Then the invoice would 
get paid.  Vendors generally would NOT send an info copy of the invoice to the 
sysprog or a reminder of renewal time. :-( 



Now that we are in our 4th year of very bad budget (layoffs and LOTS of cuts) a 
senior sysprog has to justo every single piece of software that is billed, 
regardless of how much it costs.  Tucked in behind the existing process, a 
justo for each and every product has to be written and approved up the line 
before the invoice can be paid.  This can cause a lot of delay in getting the 
bill paid.  



My experience with having to write justos and try to keep keys up to date, is 
that if the vendor will email a renewal notice with a courtesy copy of the 
invoice to the senior sysprog (listed technical contact) - and ALSO send the 
invoice directly to Accounts Payable, payments have a much better chance of 
happening on time - without the need for temporary keys or extra stress.  



Linda 


- Original Message -


From: "Brian Westerman"  
To: IBM-MAIN@bama.ua.edu 
Sent: Thursday, December 29, 2011 6:42:29 PM 
Subject: Re: cpu / machine identification 

We have  DR support in our software, but I was under the impression that most 
of the DR sites were running the OS under VM and they simulated the serial 
anyway. 

I suppose their are sites that do not run the DR under VM, but don't the sites 
who don't run under VM know the serial number ahead of time, and wouldn't it be 
already built into the software, or they have a already setup job to enter the 
new serial(s)?  I know I would have it set up if it were me. 

This also has nothing to do with the question, but I have always thought that 
the vendor should be compensated for support of the DR testing anyway.  (this 
will probably cause a lot of angry responses).  It's a separate processor and 
the vendor has to support a problem that might occur on it just like they would 
if it were the primary processor, which may not have the issue.  If that were 
the case, then the vendor has to support your DR test for free.  Now if you are 
paying $50k for the software, it's probably a reasonable expectation, but if 
you are paying $2K to $5K it's not as reasonable.   

I received an email between my last response and this one that said (a lot of 
things, but basically) that many sites (the grater percentage) don't know what 
they pay for their software because a) it's done by another department or their 
boss, or b) they only think about it when they first license the product and 
don't think about the cost involved until they either run low on budget and are 
trying to save some amount or they have a problem that makes them unhappy with 
the product that they are currently paying for. 

Is that true across the board with you people? 

Brian 


On Thu, 29 Dec 2011 17:39:58 -0500, Scott Ford  wrote: 

>ZMan I am pretty well versed in pc/unix/mf and learning Appleseed... 
>Btw I wasn't a fan of CPU/serials because DR was such a pita without new 
>product patches,etc for new CPUs.. 
> 
>Sent from my iPad 
> 
>On Dec 29, 2011, at 2:40 PM, zMan  wrote: 
> 
>> On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford  wrote: 
>>> As A vendor I understand the CPU/serial situation but one has to consider 
>>> the less than honest customers and 'yes' I have experience that also 
>>> 
>>> Sent from my iPad 
>> 
>> ...points to the liabilities of communicating using mobile devices? :-) 
>> -- 
>> zMan -- "I've got a mainframe and I'm not afraid to use it" 
>> 
>> -- 
>> For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN 
> 
>-- 
>For IBM-MAIN subscribe / signoff / archive access instructions, 
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu 

Re: cpu / machine identification

[John McKown]

On Thu, 2011-12-29 at 21:08 -0600, John McKown wrote:
> Depends on what they want to do. HIPAA is a big deal in my shop. If they
> just want SMF data, I normally run the job to create the dataset for
> them and send it to them. No big deal about that. If they want a
> "sysprog" level access (which has never happened), well, I'll do what
> I'm told. But if it were me, I'd tell them to get a court order, siting
> HIPAA. And get lots of legal documents signed by somebody like the
> president or other high officer of the company. Maybe even many
> somebodies.
> 
sed 's/siting/citing/g' 
> 
-- 
John McKown
Maranatha! <><

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

Re: IDCAMS APF auth question.

[John McKown]

Thanks! I didn't even think to read that section of the manual. "Tunnel
vision" on the APF section. My bad. Now I really wonder why the ALLOCATE
verb even exists. I guess I can understand about not allocating an
existing dataset, due to it possibly be in use by another job. Perhaps
it's for output via the OUTFILE subparameter. Hum, really need to think
about that.

On Fri, 2011-12-30 at 11:02 +0800, Cobe Xu wrote:
> Hi.
> 
> z/OS DFSMS Access Method Services for Catalogs:
> Chapter 4. ALLOCATE:
> Access method services identifies the verb name ALLOCATE and attaches the
> terminal monitor program (TMP) that runs Time Sharing Option (TSO) commands
> in the background. The ALLOCATE command *should be used only to allocate
> new data sets to the job step*. If you use ALLOCATE through access method
> services for anything else (the handling of SYSOUT data sets, for example),
> you can get unpredictable results. Refer to z/OS TSO/E Programming Guide
> for additional information on using this command. Table 2 on page 29
> separates the parameters to that you should use under access method
> services from the parameters that cause unpredictable results.
> 
> HTH..
> 

-- 
John McKown
Maranatha! <><

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

Re: cpu / machine identification

[John McKown]

We do our DR under z/VM. But we don't ask that the serial number be
altered. Unless otherwise specified in the VM guest definition, the CPU
serial number presented to z/OS is the hardware CPUID.

IIRC, you can tell z/VM to emulate the serial number, but not the
machine type. I.e. if you run on a z9BC at home, and a z10EC at DR, the
machine type will still be a z10EC even if the CPUID is changed. Again,
going by old memory, this is due to the differences in hardware
recovery.

On Thu, 2011-12-29 at 20:42 -0600, Brian Westerman wrote:
> We have  DR support in our software, but I was under the impression
> that most of the DR sites were running the OS under VM and they
> simulated the serial anyway.
> 
> I suppose their are sites that do not run the DR under VM, but don't
> the sites who don't run under VM know the serial number ahead of time,
> and wouldn't it be already built into the software, or they have a
> already setup job to enter the new serial(s)?  I know I would have it
> set up if it were me.
> 
> This also has nothing to do with the question, but I have always
> thought that the vendor should be compensated for support of the DR
> testing anyway.  (this will probably cause a lot of angry responses).
> It's a separate processor and the vendor has to support a problem that
> might occur on it just like they would if it were the primary
> processor, which may not have the issue.  If that were the case, then
> the vendor has to support your DR test for free.  Now if you are
> paying $50k for the software, it's probably a reasonable expectation,
> but if you are paying $2K to $5K it's not as reasonable.  
> 
> I received an email between my last response and this one that said (a
> lot of things, but basically) that many sites (the grater percentage)
> don't know what they pay for their software because a) it's done by
> another department or their boss, or b) they only think about it when
> they first license the product and don't think about the cost involved
> until they either run low on budget and are trying to save some amount
> or they have a problem that makes them unhappy with the product that
> they are currently paying for.
> 
> Is that true across the board with you people?
> 
> Brian
> 
> 
> On Thu, 29 Dec 2011 17:39:58 -0500, Scott Ford  wrote:
> 
> >ZMan I am pretty well versed in pc/unix/mf and learning Appleseed...
> >Btw I wasn't a fan of CPU/serials because DR was such a pita without new 
> >product patches,etc for new CPUs..
> >
> >Sent from my iPad
> >
> >On Dec 29, 2011, at 2:40 PM, zMan  wrote:
> >
> >> On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford  
> >> wrote:
> >>> As A vendor I understand the CPU/serial situation but one has to consider 
> >>> the less than honest customers and 'yes' I have experience that also
> >>>
> >>> Sent from my iPad
> >>
> >> ...points to the liabilities of communicating using mobile devices? :-)
> >> --
> >> zMan -- "I've got a mainframe and I'm not afraid to use it"
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
-- 
John McKown
Maranatha! <><

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

Re: cpu / machine identification

[John McKown]

On Thu, 2011-12-29 at 20:32 -0600, Brian Westerman wrote:
> I didn't realize that a employee can bind the site, but I can see where that 
> might actually be the case.
> 
> I can imagine what would happen to a site like IBM in Dallas, should
> Microsoft or Corel say, "we're coming on Tuesday to check every one of
> your machines".  That would be very interesting.
> 
> Brian
> 

Reminds me vaguely of an internal auditor who wanted access to the z/OS
system in order to verify that it was not compromised by Windows
viruses. Was incensed that z/OS did not have any virus scanning software
installed. Literally __could not__ understand why a Windows virus
couldn't infect the mainframe. "software is software" and "a system is a
system". Didn't understand that the z wasn't Intel compatible. Complete
IT idiot. 

-- 
John McKown
Maranatha! <><

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

Re: IDCAMS APF auth question.

[John McKown]

Guess I was a bit too vague. The ALLOCATE I was talking about was the
IDCAMS control statement. My current plan is to allocate the SYSIN DD
to /dev/fd0 (stdin) and SYSPRINT to /dev/fd1 (stdout). Unless the are
"redirected" by some sort of option. I'm still in the design phase of
what I want the command to "look like" in terms of command line.

On Thu, 2011-12-29 at 21:35 -0500, Scott Ford wrote:
> John,
> I would say you will have to allocate the sysin dataset and sysprint.
> I have called in COBOL via bpxwdyn allocating sysin and sysprint, but wasnt 
> idcams.
> I don't see why you couldn't do the same for idcams
> 
> Sent from my iPad
> 
> On Dec 29, 2011, at 7:50 PM, John McKown  wrote:
> 
> > I am writing a program which will ATTACH IDCAMS to do some things. I
> > have been reading:
> > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2I2A0/D.1
> > which goes over the commands which require APF authorization. I have one
> > question that perhaps someone here knows the answer to. The above
> > states:
> > 
> > An address space that calls IDCAMS to issue any of these commands must
> > be APF authorized, or the command will terminate:
> > 
> >  * ALLOCATE command to allocate an SMS-managed data set
> > 
> > 
> > What is the meaning of the second "allocate" in that sentence? Does it
> > mean "create" as in "allocate a new" or does it mean the more generic
> > "allocate" as in "do a dynamic allocation" even if the dataset already
> > exists?
> > 
> > I know, "try it and see". When I get to that point, I will. I'm writing
> > a UNIX command (in HLASM) which runs IDCAMS from a UNIX shell prompt.
> > I'm still in the design stage on what I want it to "look like" in terms
> > of options and arguments.
> > 
> > -- 
> > John McKown
> > Maranatha! <><
> > 
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
-- 
John McKown
Maranatha! <><

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

Re: IDCAMS APF auth question.

[Cobe Xu]

Hi.

z/OS DFSMS Access Method Services for Catalogs:
Chapter 4. ALLOCATE:
Access method services identifies the verb name ALLOCATE and attaches the
terminal monitor program (TMP) that runs Time Sharing Option (TSO) commands
in the background. The ALLOCATE command *should be used only to allocate
new data sets to the job step*. If you use ALLOCATE through access method
services for anything else (the handling of SYSOUT data sets, for example),
you can get unpredictable results. Refer to z/OS TSO/E Programming Guide
for additional information on using this command. Table 2 on page 29
separates the parameters to that you should use under access method
services from the parameters that cause unpredictable results.

HTH..

On Fri, Dec 30, 2011 at 8:50 AM, John McKown  wrote:

> I am writing a program which will ATTACH IDCAMS to do some things. I
> have been reading:
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2I2A0/D.1
> which goes over the commands which require APF authorization. I have one
> question that perhaps someone here knows the answer to. The above
> states:
> 
> An address space that calls IDCAMS to issue any of these commands must
> be APF authorized, or the command will terminate:
>
>  * ALLOCATE command to allocate an SMS-managed data set
> 
>
> What is the meaning of the second "allocate" in that sentence? Does it
> mean "create" as in "allocate a new" or does it mean the more generic
> "allocate" as in "do a dynamic allocation" even if the dataset already
> exists?
>
> I know, "try it and see". When I get to that point, I will. I'm writing
> a UNIX command (in HLASM) which runs IDCAMS from a UNIX shell prompt.
> I'm still in the design stage on what I want it to "look like" in terms
> of options and arguments.
>
> --
> John McKown
> Maranatha! <><
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>



-- 
Cobe Xu

Best Regards
---
z/OS Performance & Capacity Analyst
z/OS System Programmer
Email: cob...@gmail.com
---

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

Re: cpu / machine identification

[Brian Westerman]

We have  DR support in our software, but I was under the impression that most 
of the DR sites were running the OS under VM and they simulated the serial 
anyway.

I suppose their are sites that do not run the DR under VM, but don't the sites 
who don't run under VM know the serial number ahead of time, and wouldn't it be 
already built into the software, or they have a already setup job to enter the 
new serial(s)?  I know I would have it set up if it were me.

This also has nothing to do with the question, but I have always thought that 
the vendor should be compensated for support of the DR testing anyway.  (this 
will probably cause a lot of angry responses).  It's a separate processor and 
the vendor has to support a problem that might occur on it just like they would 
if it were the primary processor, which may not have the issue.  If that were 
the case, then the vendor has to support your DR test for free.  Now if you are 
paying $50k for the software, it's probably a reasonable expectation, but if 
you are paying $2K to $5K it's not as reasonable.  

I received an email between my last response and this one that said (a lot of 
things, but basically) that many sites (the grater percentage) don't know what 
they pay for their software because a) it's done by another department or their 
boss, or b) they only think about it when they first license the product and 
don't think about the cost involved until they either run low on budget and are 
trying to save some amount or they have a problem that makes them unhappy with 
the product that they are currently paying for.

Is that true across the board with you people?

Brian


On Thu, 29 Dec 2011 17:39:58 -0500, Scott Ford  wrote:

>ZMan I am pretty well versed in pc/unix/mf and learning Appleseed...
>Btw I wasn't a fan of CPU/serials because DR was such a pita without new 
>product patches,etc for new CPUs..
>
>Sent from my iPad
>
>On Dec 29, 2011, at 2:40 PM, zMan  wrote:
>
>> On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford  wrote:
>>> As A vendor I understand the CPU/serial situation but one has to consider 
>>> the less than honest customers and 'yes' I have experience that also
>>>
>>> Sent from my iPad
>>
>> ...points to the liabilities of communicating using mobile devices? :-)
>> --
>> zMan -- "I've got a mainframe and I'm not afraid to use it"
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: cpu / machine identification

[Brian Westerman]

I didn't realize that a employee can bind the site, but I can see where that 
might actually be the case.

I can imagine what would happen to a site like IBM in Dallas, should Microsoft 
or Corel say, "we're coming on Tuesday to check every one of your machines".  
That would be very interesting.

Brian

 On Thu, 29 Dec 2011 14:47:21 -0500, Tony Harminc  wrote:

>On 28 December 2011 20:58, Brian Westerman
> wrote:
>> I don't mean to be flippant, but I seriously almost spit my diet coke all 
>> over my screen when I read the previous reply about allowing the software 
>> company to audit their system. :)
>>
>> I really don't think any site would readily agree to have their site 
>> "audited" by a software company for compliance.
>>
>> It sounds good to say that, but in reality I really really doubt that anyone 
>> at just about any site would agree to it.  I can just imagine the dead 
>> silence that would happen when a marketing person says "oh yeh, and we will 
>> be here in sometime during the year and audit all of your CPU's and LPARs to 
>> make sure we can "really" trust you".
>>
>> After the silence, the sale would disappear. :)
>>
>> Please don't take offense with my response.  It just took me by surprise.
>
>I've seen Fortune 500 companies happily sign mainframe software
>contracts with vendor written auditing provisions; others who[se
>lawyers] routinely snipped out the auditing paragraph without comment,
>and others who negotiated the details.
>
>BTW, a number of popular desktop software products from well known
>vendors have audit clauses in the click-through licence agreement.
>Usually corporate Contracts doesn't see those, and it's less than
>clear if the individual employee can bind the company by clicking
>Accept.
>
>I've also seen what happened when a vendor tried to do an audit -
>consisting of asking for a subset of SMF records - on a random set of
>customers, some with audit clauses and some without, and for the most
>part it wasn't pleasant in either case.
>
>Tony H.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: cpu / machine identification

[Brian Westerman]

Sorry,

I found out that the quote is not on by default (the hard way :)) and also that 
I have to click on it BEFORE I enter any data.

I was answering a response that stated that if a site has a site license, that 
there should be no constraints on the code, but I wanted to point out that not 
all sites license the code for the entire site (some is for a single CPU or 
LPAR), and that there is no protection against the software becoming part of 
some systems programmer's goodie bag when he/she moves to the next site.  You 
can limit by date, that also doesn't provide proper protections.

I had wanted to point out that people lock their cars, even when they have the 
only key.  There are people that even lock their car in their own garage.  It's 
more work to unlock the car, but they do it anyway.  If you take your car to 
the shop to be worked on and park it in their lot, do you lock it?  Do they 
lock it when they are done?

When you take your key out of the ignition, the steering wheel locks in place.  
You can't turn the wheel without inserting your key, some people see that as a 
safety feature, others as a anti-theft feature, some people break the 
inter-lock that controls that "feature".  The safety and anti-theft parts have 
long since been rendered useless because of the technology in the cars computer 
circuitry, but if a car was shipped without the "feature" most people would see 
that as a defect and take it back to be fixed.

Actually reading back on the previous paragraph, it gets more away from the 
point than I wanted to be, but I'll leave it anyway because (while really 
tangential), it makes a point that I wanted to get to which is that the extra 
work required for something, in this case the maintenance of the keys for 
software at the site, is a bummer, but is also necessary because there are some 
sites (and some people) who will just not follow directions or abide by the 
rules and you cannot reasonably expect the vendor to take all the risk.  

Small vendors might know all of their clients personally and know if they can 
trust them with their code, frankly, if they do then they probably don't have 
very many clients.

A company like IBM or CA, who makes billions a year, can afford to be lax on 
control of their software (although CA isn't really that lax), and they up the 
price to everyone to make up for the "possibility" that someone isn't paying.  
The software has long since paid for itself and in many cases, there is other 
software that is better and cheaper, but people still see them as the first 
choice.  I'm not sure why, maybe it's like with a car, you wouldn't buy a car 
from Chevrolet and get the doors from Ford, even if Ford has a better door that 
fits perfectly.  It probably has nothing to do with that, but I honestly don't 
know why it is.

Our automation software is years ahead of IBM and CA's, and theirs cost 90 to 
95% more, but they still have the biggest market shares in automation software. 
 I don't know why, marketing might have something to do with it, but it's not 
like you see big marketing pushes for their automation software anywhere so I 
just don't know why it is.

The one thing I do know is that vendors have the right to protect their 
software and as long as it's reasonable protection, I don't see why a site 
would complain about it.  Most sites do not complain, but obviously some do, 
that's what started the thread after the person who entered the original 
request asked for comments.

Brian

 On Thu, 29 Dec 2011 15:02:14 +, Pommier, Rex R. 
 wrote:

>Brian,
>
>I see your point, but have a request for you.  Don't get quite so aggressive 
>with the electronic scissors on snipping away the context.  The beginning of 
>your comment below says it all - "That works...".  What's "that"?  Since there 
>have been several comments/points of view made, it would be much easier to 
>leave the comment you are replying to in your reply.
>
>Not trying to be flippant, mind you.  :-)
>
>Rex
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
>Brian Westerman
>Sent: Wednesday, December 28, 2011 8:02 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: cpu / machine identification
>
>That works for a site license and I agree with it for that type of license, 
>but what about sites that purchase a single processor license and have 4 
>processors, or a systems programmer that decides that he can fix his "friends" 
>problem by sending a copy of the code to them, or the one that decides to post 
>the code on facebook.  (I reaching with the facebook thing, but hopefully you 
>see my point).
>
>Brian
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>The information contained in this e-mail may contain confidential and/or 
>privileged information and is intended fo

Re: IDCAMS APF auth question.

[Scott Ford]

John,
I would say you will have to allocate the sysin dataset and sysprint.
I have called in COBOL via bpxwdyn allocating sysin and sysprint, but wasnt 
idcams.
I don't see why you couldn't do the same for idcams

Sent from my iPad

On Dec 29, 2011, at 7:50 PM, John McKown  wrote:

> I am writing a program which will ATTACH IDCAMS to do some things. I
> have been reading:
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2I2A0/D.1
> which goes over the commands which require APF authorization. I have one
> question that perhaps someone here knows the answer to. The above
> states:
> 
> An address space that calls IDCAMS to issue any of these commands must
> be APF authorized, or the command will terminate:
> 
>  * ALLOCATE command to allocate an SMS-managed data set
> 
> 
> What is the meaning of the second "allocate" in that sentence? Does it
> mean "create" as in "allocate a new" or does it mean the more generic
> "allocate" as in "do a dynamic allocation" even if the dataset already
> exists?
> 
> I know, "try it and see". When I get to that point, I will. I'm writing
> a UNIX command (in HLASM) which runs IDCAMS from a UNIX shell prompt.
> I'm still in the design stage on what I want it to "look like" in terms
> of options and arguments.
> 
> -- 
> John McKown
> Maranatha! <><
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: cpu / machine identification

[Brian Westerman]

I'm sorry Schmuel, normally I agree with your point on things, but I really 
have to disagree here.  It's not like I have no experience with other sites, we 
have hundreds of clients, and I have been to well over 80% of them in person, 
and I can state without much worry that the percentages would not be on my side 
that the far greater percentage (approaching 100%) would never agree to giving 
a vendor access to their site to "check up" on them.

Even when we go to a site as the "IBM" people, they go way out of their way to 
make sure that we stay focused on the problem and don't just "look around".  As 
a "non IBM" vendor, it would be even less likely that the client would just 
open their site to us.

In this case I hardily agree with the view that the the vendor would be told to 
go pound salt.  Imagine the security issues that would have to be dealt with to 
just give them an ID that has the capability to check.  

Brian


On Thu, 29 Dec 2011 05:02:06 -0500, Shmuel Metz (Seymour J.) 
 wrote:

>In <7026723933836234.wa.brianwestermansyzygyinc@bama.ua.edu>, on
>12/28/2011
>   at 07:58 PM, Brian Westerman  said:
>
>>I really don't think any site would readily agree to have their site
>>"audited" by a software company for compliance.
>
>Why not?
>
>>After the silence, the sale would disappear. :)
>
>Perhaps at your site.
>
>--
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see 
>We don't care. We don't have to care, we're Congress.
>(S877: The Shut up and Eat Your spam act of 2003)
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: cpu / machine identification

[Brian Westerman]

Another test,

Okay, it appears that I have to click on the quote on the bottom right BEFORE I 
type anything here, so now I think I have it right.  Is there a way to turn on 
Quoting as a default?

Brian

On Thu, 29 Dec 2011 19:36:49 -0600, Brian Westerman 
 wrote:

>Sorry about that, I was sure that the original messages were appended, but I 
>am obviously wrong.  I think I probably just clicked on the send message 
>without pressing the quote first.
>
>Sorry again,
>
>Brian
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: cpu / machine identification - testing quote

[Brian Westerman]

This is a test to see if I am getting the quote by pressing the quote button at 
the bottom right

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

Re: cpu / machine identification

[Brian Westerman]

This is a test to see if the quote button on the bottom right is working.

Brian

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

Re: cpu / machine identification

[Brian Westerman]

Sorry about that, I was sure that the original messages were appended, but I am 
obviously wrong.  I think I probably just clicked on the send message without 
pressing the quote first.

Sorry again,

Brian

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

Re: XML Generate String Length

[Roberts, John J]

>   One of our developers is performing an XML GENERATE with a string that's 
> variable. >When it gets above
>about 100K, it ASRA's. No error codes or anything.

David, you might want to ask Paul Cooper over on the CICS-L listserv, since I 
think you are doing XML GENERATE in the CICS context (ASRA abend).  There are 
plenty of storage limits in the CICS environment, some as small as 32KB.

Also, version 4 of the Enterprise COBOL compiler introduced a new XML parser 
and probably a new generator, so this could complicate matters.  There is a 
compiler parameter to select the old versus new XML behavior (XMLCOMPAT IIRC).

John

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

Re: Looking for Mailing List

[Chris Mason]

John

More precisely:

For IBMTCP-L subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO IBMTCP-L

Chris Mason

On Thu, 29 Dec 2011 14:49:43 -0500, Tony Harminc  wrote:

>On 29 December 2011 14:38, John P. Baker  wrote:
>
>> I am looking for a mailing list where I can pose questions specific to the
>> EZASMI TCP/IP socket programming interface.
>
>> Can anyone offer any suggestions?
>
>I believe the IBM-TCP list (ibmtc...@vm.marist.edu) covers all of the
>TCP/IP APIs.
>
>Tony H.

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

IDCAMS APF auth question.

[John McKown]

I am writing a program which will ATTACH IDCAMS to do some things. I
have been reading:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2I2A0/D.1
which goes over the commands which require APF authorization. I have one
question that perhaps someone here knows the answer to. The above
states:

An address space that calls IDCAMS to issue any of these commands must
be APF authorized, or the command will terminate:

  * ALLOCATE command to allocate an SMS-managed data set


What is the meaning of the second "allocate" in that sentence? Does it
mean "create" as in "allocate a new" or does it mean the more generic
"allocate" as in "do a dynamic allocation" even if the dataset already
exists?

I know, "try it and see". When I get to that point, I will. I'm writing
a UNIX command (in HLASM) which runs IDCAMS from a UNIX shell prompt.
I'm still in the design stage on what I want it to "look like" in terms
of options and arguments.

-- 
John McKown
Maranatha! <><

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

XML Generate String Length

[Kopischke, David G.]

Greetings,
   One of our developers is performing an XML GENERATE with a string that's 
variable. When it gets above
about 100K, it ASRA's. No error codes or anything.

   Is there a maximum message length ??? 100K seems too small for an IBM limit, 
so there's probably a
parameter somewhere that I'm missing. I'm still looking, but let me know if you 
can point me to a manual
reference.

Thanks,
   Dave K.


--
This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications. 
==

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

Re: cpu / machine identification

[Scott Ford]

ZMan I am pretty well versed in pc/unix/mf and learning Appleseed...
Btw I wasn't a fan of CPU/serials because DR was such a pita without new 
product patches,etc for new CPUs..

Sent from my iPad

On Dec 29, 2011, at 2:40 PM, zMan  wrote:

> On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford  wrote:
>> As A vendor I understand the CPU/serial situation but one has to consider 
>> the less than honest customers and 'yes' I have experience that also
>> 
>> Sent from my iPad
> 
> ...points to the liabilities of communicating using mobile devices? :-)
> -- 
> zMan -- "I've got a mainframe and I'm not afraid to use it"
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: removing nulls from a file

[Wissink, Brad [ITSYS]]

The first two bytes are 'FF FE'.  I tried saving it with UTF-8 and it removed 
all the nulls and looks correct now.  Now just need to talk to the client to do 
this when they save the file.

Thanks for all the help.

Brad Wissink
Information Technology Services
Iowa State University
515-294-3088

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
zMan
Sent: Thursday, December 29, 2011 1:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: removing nulls from a file

On Thu, Dec 29, 2011 at 1:18 PM, Frank Swarbrick  
wrote:
> I agree, it looks like the original file is encoded in small-endian UTF-16.
> If the file is generated on a Windows system and there's no way to change the 
> creating software to use UTF-8 or an ASCII code page (I'm betting there is, 
> if one looks hard enough) you can probably use Windows Notepad to convert 
> it.  Just open it in Notepad, so a "Save As" and change the Encoding from 
> Unicode (which is UTF-16) to ANSI.
>
> But in the end, it really should be up to the system that creates the file to 
> have an ANSI/ASCII option...

I've seen this a lot from Microsoft stuff -- export a Registry key, for 
example, and look at it on Windows and you'll see this. I suspect the encoding 
is the right answer.
--
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

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

Re: Looking for Mailing List

[John P. Baker]

Tony,

Thanks for the pointer.

John P. Baker

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Tony Harminc
Sent: Thursday, December 29, 2011 2:50 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Looking for Mailing List

On 29 December 2011 14:38, John P. Baker  wrote:

> I am looking for a mailing list where I can pose questions specific to 
> the EZASMI TCP/IP socket programming interface.

> Can anyone offer any suggestions?

I believe the IBM-TCP list (ibmtc...@vm.marist.edu) covers all of the TCP/IP
APIs.

Tony H.

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

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

Re: cpu / machine identification

[Tony Harminc]

On 28 December 2011 20:58, Brian Westerman
 wrote:
> I don't mean to be flippant, but I seriously almost spit my diet coke all 
> over my screen when I read the previous reply about allowing the software 
> company to audit their system. :)
>
> I really don't think any site would readily agree to have their site 
> "audited" by a software company for compliance.
>
> It sounds good to say that, but in reality I really really doubt that anyone 
> at just about any site would agree to it.  I can just imagine the dead 
> silence that would happen when a marketing person says "oh yeh, and we will 
> be here in sometime during the year and audit all of your CPU's and LPARs to 
> make sure we can "really" trust you".
>
> After the silence, the sale would disappear. :)
>
> Please don't take offense with my response.  It just took me by surprise.

I've seen Fortune 500 companies happily sign mainframe software
contracts with vendor written auditing provisions; others who[se
lawyers] routinely snipped out the auditing paragraph without comment,
and others who negotiated the details.

BTW, a number of popular desktop software products from well known
vendors have audit clauses in the click-through licence agreement.
Usually corporate Contracts doesn't see those, and it's less than
clear if the individual employee can bind the company by clicking
Accept.

I've also seen what happened when a vendor tried to do an audit -
consisting of asking for a subset of SMF records - on a random set of
customers, some with audit clauses and some without, and for the most
part it wasn't pleasant in either case.

Tony H.

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

Re: removing nulls from a file

[zMan]

On Thu, Dec 29, 2011 at 1:18 PM, Frank Swarbrick
 wrote:
> I agree, it looks like the original file is encoded in small-endian UTF-16.
> If the file is generated on a Windows system and there's no way to change the 
> creating software to use UTF-8 or an ASCII code page (I'm betting there is, 
> if one looks hard enough) you can probably use Windows Notepad to convert 
> it.  Just open it in Notepad, so a "Save As" and change the Encoding from 
> Unicode (which is UTF-16) to ANSI.
>
> But in the end, it really should be up to the system that creates the file to 
> have an ANSI/ASCII option...

I've seen this a lot from Microsoft stuff -- export a Registry key,
for example, and look at it on Windows and you'll see this. I suspect
the encoding is the right answer.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: Looking for Mailing List

[Tony Harminc]

On 29 December 2011 14:38, John P. Baker  wrote:

> I am looking for a mailing list where I can pose questions specific to the
> EZASMI TCP/IP socket programming interface.

> Can anyone offer any suggestions?

I believe the IBM-TCP list (ibmtc...@vm.marist.edu) covers all of the
TCP/IP APIs.

Tony H.

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

Re: Regarding LE control blocks

[zMan]

On Thu, Dec 29, 2011 at 8:43 AM, Binyamin Dissen
 wrote:
> It is at a customer.  But why would the older enclave, FOO, be cleaning up
> COBOL when COBOL did not run in that enclave?

Because LE is LE is LE -- I don't think it "knows" that it's COBOL
(well, of course it *does*, but it doesn't care).
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Looking for Mailing List

[John P. Baker]

All,

 

I am looking for a mailing list where I can pose questions specific to the
EZASMI TCP/IP socket programming interface.

 

Can anyone offer any suggestions?

 

John P. Baker


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

Re: cpu / machine identification

[zMan]

On Thu, Dec 29, 2011 at 10:25 AM, Scott Ford  wrote:
> As A vendor I understand the CPU/serial situation but one has to consider the 
> less than honest customers and 'yes' I have experience that also
>
> Sent from my iPad

...points to the liabilities of communicating using mobile devices? :-)
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: Clarification on Sysres Volumes(RMF)

[Ulrich Krueger]

Jags,
Is your GRS-plex set up properly to propagate ENQs and RESERVEs across all
the systems in your shared DASD complex?
IMHO, under normal conditions, you should not have hard RESERVEs on a disk
impacting your systems.


Regards,
Ulrich Krueger


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of jagadishan perumal
Sent: Wednesday, December 28, 2011 11:10 PM
To: IBM-MAIN@bama.ua.edu
Subject: Clarification on Sysres Volumes(RMF)

Hi,

I was examining the RMF delay report where below is the report :

   Speed of 100 = Maximum, 0 = Stopped Average CPU Util:
19 %
Name   Users Active  Speed  Name   Users Active
Speed
*SYSTEM  203 58  8  *DEV 107
54  8
ALL TSO  119 52  5  *MASTER*   1  0
56
ALL STC   74  3
40
ALL BATCH  8  4
21
ALL ASCH Not
avail
ALL OMVS   2  0No
work
*PROC129  3
7


-- Exceptions
-
Name   ReasonCritical val. Possible cause or
action
DOV0053DEV -Z18RS193.0 % delay May be reserved by another
system.
DOV0061DEV -Z18RS192.0 % delay May be reserved by another
system.
DOV0065DEV -Z18RS191.0 % delay May be reserved by another
system.

The above exceptions shows lot of device contention due to which often we
are facing a session hang. Also, Device display shows the status as
BSY(busy). Could anyone please throw some light on the above issue.

Jags

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

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

Re: Clarification on Sysres Volumes(RMF)

[Lizette Koehler]

> 
> Hi,
> 
> I was examining the RMF delay report where below is the report :
> 
>Speed of 100 = Maximum, 0 = Stopped Average CPU Util:
> 19 %
> Name   Users Active  Speed  Name   Users Active
> Speed
> *SYSTEM  203 58  8  *DEV 107
> 54  8
> ALL TSO  119 52  5  *MASTER*   1  0
> 56
> ALL STC   74  3
> 40
> ALL BATCH  8  4
> 21
> ALL ASCH Not
> avail
> ALL OMVS   2  0No
> work
> *PROC129  3
> 7
> 
> 
> -- Exceptions
> -
> Name   ReasonCritical val. Possible cause or
> action
> DOV0053DEV -Z18RS193.0 % delay May be reserved by another
> system.
> DOV0061DEV -Z18RS192.0 % delay May be reserved by another
> system.
> DOV0065DEV -Z18RS191.0 % delay May be reserved by another
> system.
> 
> The above exceptions shows lot of device contention due to which often we
are facing
> a session hang. Also, Device display shows the status as BSY(busy). Could
anyone
> please throw some light on the above issue.
> 
> Jags


Jags,

What is on your SYSRES Volume?  Do you have datasets that get updated there?
You have to review the datasets and see which ones are getting hit the most.
What do you have on your sysres volume that has a high usage?  If you have
MXG or MICS it can help you answer that question.

You need to research this and see what is impacting the sysres volume.

Lizette

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

Re: removing nulls from a file

[Frank Swarbrick]

I agree, it looks like the original file is encoded in small-endian UTF-16.
If the file is generated on a Windows system and there's no way to change the 
creating software to use UTF-8 or an ASCII code page (I'm betting there is, if 
one looks hard enough) you can probably use Windows Notepad to convert it.  
Just open it in Notepad, so a "Save As" and change the Encoding from Unicode 
(which is UTF-16) to ANSI.

But in the end, it really should be up to the system that creates the file to 
have an ANSI/ASCII option...

Frank




>
> From: "McKown, John" 
>To: IBM-MAIN@bama.ua.edu 
>Sent: Thursday, December 29, 2011 10:17 AM
>Subject: Re: removing nulls from a file
> 
>Sounds like the original file is UTF-16. The simpliest thing is to convert it 
>to UTF-8 before transferring. But I know that many "clients" are not 
>knowledgable enough to do this. If you transfer this into a UNIX file on z/OS, 
>then it is rather simple. Use the 'tr' command.
>
>tr -d '\000' output.file
>
>If in a z/OS dataset, you might want to try:
>
>cp -T "//'HLQ.INPUT.FILE'" /dev/fd1 |\
>tr -d '/000' |\
>cp -T /dev/fd0 "//'HLQ.OUTPUT.FILE'"
>
>I would preallocate the output file to establish the DCB and space parameters. 
>
>--
>John McKown 
>Systems Engineer IV
>IT
>
>Administrative Services Group
>
>HealthMarkets(r)
>
>9151 Boulevard 26 * N. Richland Hills * TX 76010
>(817) 255-3225 phone * 
>john.mck...@healthmarkets.com * www.HealthMarkets.com
>
>Confidentiality Notice: This e-mail message may contain confidential or 
>proprietary information. If you are not the intended recipient, please contact 
>the sender by reply e-mail and destroy all copies of the original message. 
>HealthMarkets(r) is the brand name for products underwritten and issued by the 
>insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
>Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
>MEGA Life and Health Insurance Company.SM
>
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List 
>> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Brad Wissink
>> Sent: Thursday, December 29, 2011 9:20 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: removing nulls from a file
>> 
>> We have a client that is trying to transfer us a file and it 
>> is loaded with nulls.  They say that is the way it comes from 
>> the purchased software they have on their workstation.  The 
>> file has a null character inserted after every character so 
>> it looks like this
>> 
>> 1 12/29/2011   becomes  
>> F1004000F100F2006100F200F9006100F200F000F100F100...
>> 
>> Has anyone seen anything like this before?  Is there a quick 
>> and easy way to remove all the nulls?
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>> 
>> 
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>
>

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

Re: PCOMM & access to workstation file system

[Dave Salt]

> On Thu, 29 Dec 2011 12:43:27 +0200, Itschak Mugzach wrote:
> >As I wrote in previous mails, my interest is not in working in a client 
> >server mode 
> 

> From: m42tom-ibmm...@yahoo.com:
> WSA does much more useful things (IMO) than allow you to work in 
> client server mode.  I use it mostly for file transfer, but have played 
> with its ability to edit PC files using the ISPF editor.  Dave Salt might 
> step in to list other capabilities of the connection.

I use the ISPF Workstation Agent (WSA) almost every day and I couldn't imagine 
working without it. Having said that, I never use it in client server mode. 

When you enter the WSCON command on any ISPF command line, a panel is displayed 
that prompts you for the IP address of the workstation you wish to connect to; 
i.e. the address of the PC where WSA.EXE has been launched. In addition to 
entering the IP address the panel also prompts you for the following:

Workstation Connection   
1. With GUI display   
2. Without GUI display

The default value in this field is initially set to '1', which causes ISPF to 
open in a window on the PC. It also 'freezes' the mainframe session so you can 
ONLY work on the PC. This is known as "client server mode", and many people 
(myself included) find it UGLY. I strongly recommend changing the value to '2' 
(i.e. WITHOUT GUI display), as this allows you to continue working on the 
mainframe just as you normally would. This means you're NOT working in client 
server mode, even though you DO have a full connection between the mainframe 
and PC.

One of the major benefits of having a workstation connection is that file 
transfers become extremely easy to perform. For example, you can transfer 
members by simply selecting them from a member list in ISPF option 3.7.2. 
Another benefit is that you can edit PC files on the mainframe (e.g. by 
entering a PC file name in the Workstation field in ISPF option 2), or edit 
mainframe files on the PC (e.g. by selecting the "Edit on workstation" field in 
ISPF option 2). 

You can also write your own mainframe applications to do just about anything 
you can imagine; e.g. send mainframe files to be printed on a local PC printer 
(which is extremely convenient if you work from home and don't have access to a 
mainframe printer). You can click URLs displayed on an ISPF panel to launch a 
browser and open a web site, or select any type of file from a mainframe 
session (e.g. a WORD document) and have it open on the PC, or send commands to 
be executed on the PC, or display on the mainframe the names of all the files 
in a PC directory so they can be selected for various functions (e.g. browse, 
edit, print, transfer, etc).

By way of example, here are some of the objects I keep in one of my SimpList 
object lists:

 _   OBJ   1   ?==> C:\users\dave\temp.txt{Open file on mainframe   
  
 _   OBJ   2   ?==> C:\users\dave\dave1\*.txt {List PC files on mainframe 
 _   OBJ   3   ?==>     
 _   OBJ   9   ?==> {These commands execute from a command prompt window:  
 _   OBJ  10   ?==>   
 _   OBJ  26   ?==> {These commands execute from a Windows RUN prompt: 
 _   OBJ  27   ?==>msmsgs.inf,BLC.Remove   {Remove MSN from XP laptop
 _   OBJ  38   ?==> 
 _   OBJ  40   ?==> {CALL MSCONFIG (WHICH ISN'T IN SEARCH PATH) FROM WIN7  
 _   OBJ  41   ?==> <"C:\WINDOWS\SYSTEM32\MSCONFIG.EXE"   {Execute immediately 
 _   OBJ  42   ?==> 
 _   OBJ  44   ?==> {Execute a BAT file (contains DIR cmd) in a command window:
 _   OBJ  45   ?==> <"C:\Demo\temp file.bat"   
 _   OBJ  46   ?==>
 _   OBJ  47   ?==> {Open local and remote PDF file:   
 _   OBJ  48   ?==> .exe "C:\Demo\SimpList User Guide (v2r1).pdf"   
 _   OBJ  50   ?==> {The above has been set to a permanent symbol called &PDF  
 _   OBJ  51   ?==> &PDF "C:\Demo\SIM20.pdf"  {Local  PDF  
 _   OBJ  52   ?==> &PDF "\\Soft-Center\XP C\Demo\SIM20.pdf"  {File on laptop  
 _   OBJ  53   ?==> &PDF "\\Vista\C\Demo\SIM20.pdf"   {File on desktop 
 _   OBJ  54   ?==>
 _   OBJ  55   ?==> {Open a WORD document from the Vista desktop:  
 _   OBJ  56   ?==>  {The above has been set to a permanent symbol called &WRD12
 _   OBJ  58   ?==>  &WRD12 "

Re: removing nulls from a file

[Steve Comstock]

On 12/29/2011 10:17 AM, Scott Ford wrote:

I have seen this on a SYSOUT created with a Cobol program
Moving spaces to a print line can cause nulls for sure...


Huh? How?



How is the file transferred ?  Binary will not change anything, but if they 
transfer it with CR/LF and ebcdic to ascii enabled ...
Could be interesting

Scott J Ford
Software Engineer
http://www.identityforge.com




  From: Joel C. Ewing
To: IBM-MAIN@bama.ua.edu
Sent: Thursday, December 29, 2011 12:10 PM
Subject: Re: removing nulls from a file

On 12/29/2011 09:19 AM, Brad Wissink wrote:

We have a client that is trying to transfer us a file and it is loaded with 
nulls.  They say that is the way it comes from the purchased software they have 
on their workstation.  The file has a null character inserted after every 
character so it looks like this

1 12/29/2011   becomes  F1004000F100F2006100F200F9006100F200F000F100F100...

Has anyone seen anything like this before?  Is there a quick and easy way to 
remove all the nulls?



It's almost as if they are using software that somehow mistakenly thinks EBCDIC 
is a two-byte character encoding, or the process for conversion to EBCDIC was 
written by a neophyte programmer who treated each character as a 
null-terminated string and some how managed to include the null termination for 
each character when outputting the converted data.  Maybe they have their 
software package mis-configured in some way, or since they are talking about 
workstation software producing the data, the software package generating the 
data may be ignorant of EBCDIC and the fault may be in what technique they are 
using after-the-fact to either convert the data to EBCDIC or transmit the data 
with conversion.

If at all possible, try to get clarification of exactly what software and 
options they are using to produce the data and exactly what technique and 
options they are using to transmit the data.  If possible, get them to transmit 
via other methods (Email, FTP, etc.) samples of any intermediate files as 
binary data so you can see exactly what data format they are really dealing 
with on their workstation (as opposed to what the client may think he has).  If 
they are really transmitting twice the number of needed bytes, fixing the 
problem at their end would be the better solution.  Perhaps given enough 
background on what they are doing, a solution would become obvious, or you 
would be able to search on-line for a solution if the client lacks the 
technical expertise to do so on their own.

If everything is kosher on their end and the byte doubling is somehow occurring 
just on your receiving system, then hopefully you will have enough to be able 
to recreate and fix the problem on your end.  Just cleaning up bad data after 
the fact will work, but is not as desirable as eliminating the creation of the 
bad data in the first place.

-- Joel C. Ewing,Bentonville, AR  jcew...@acm.org

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

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




--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

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

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

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

Re: Semiprivileged instructions, part 1

[Gerhard Postpischil]

On 12/29/2011 8:57 AM, Peter Relson wrote:

z/OS itself does not provide support for TRAP2/TRAP4. But some
(authorized) program products do this on their own (a bad decision not to
have this provided by the operating system).

 ...

The long and short of it is that you can't use
TRAP2/TRAP4 "on your own" if you are not privileged.


These are the two instructions I love to hate. Life would be a 
lot simpler had they be implemented as No-Ops unless trapping 
was enabled. Some years ago I was assigned to debug an LPA 
resident program that had mysterious, intermittent failures, but 
always worked while being tested. Because the failure modes 
differed (e.g., bad data rather than an interrupt), SLIP was of 
limited utility. Had there been a benign form of TRAP (ignored 
by other tasks) it would have been a lot easier to track this 
(turned out to be an uninitialized variable).


Gerhard Postpischil
Bradford, VT

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

Re: Question on adding an SVC routine dynamically to a running system

[Joel C. Ewing]

On 12/29/2011 11:06 AM, Dave Day wrote:

Answering my own question, just for the record. I just tried it, and
there is no need to actually have the module in the LPA chain. SVCUPDTE
does indeed update the SVC table, and the SVC can be executed with no
problems.

--Dave Day
- Original Message - From: "Dave Day" 
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Thursday, December 29, 2011 9:00 AM
Subject: Question on adding an SVC routine dynamically to a running system


The auth services guide in the chapter on user SVCs, states a type 3
needs to be in LPA. Yet the SVCUPDATE will accept, and update the svc
table, an address in ECSA. Do I need to add the routine to LPA using
CSVDYLPA prior to SVCUPDATE?

--Dave Day


If the intent was a permanent change, just be sure you DO get 
appropriate parmlib and/or module location changed before next IPL, so 
you don't get surprised by unexpectedly losing your updated SVC at next 
IPL.  I always tried to do both updates at about the same time under the 
assumption that Murphy might arrange for unscheduled IPLs at his 
convenience, not mine.


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: removing nulls from a file

[Ray Pearce]

Could it be Unicode that has been translated to EBCDIC as if it were
ASCII?
Check the first two bytes, if they are FE FF then it was almost
certainly Unicode.

 -
This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 internal virus protection system.
 -

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

Re: removing nulls from a file

[Scott Ford]

I have seen this on a SYSOUT created with a Cobol programMoving spaces to a 
print line can cause nulls for sure...
 
How is the file transferred ?  Binary will not change anything, but if they 
transfer it with CR/LF and ebcdic to ascii enabled ... 
Could be interesting
 
Scott J Ford
Software Engineer
http://www.identityforge.com
 
 


 From: Joel C. Ewing 
To: IBM-MAIN@bama.ua.edu 
Sent: Thursday, December 29, 2011 12:10 PM
Subject: Re: removing nulls from a file
 
On 12/29/2011 09:19 AM, Brad Wissink wrote:
> We have a client that is trying to transfer us a file and it is loaded with 
> nulls.  They say that is the way it comes from the purchased software they 
> have on their workstation.  The file has a null character inserted after 
> every character so it looks like this
> 
> 1 12/29/2011   becomes  
> F1004000F100F2006100F200F9006100F200F000F100F100...
> 
> Has anyone seen anything like this before?  Is there a quick and easy way to 
> remove all the nulls?
> 

It's almost as if they are using software that somehow mistakenly thinks EBCDIC 
is a two-byte character encoding, or the process for conversion to EBCDIC was 
written by a neophyte programmer who treated each character as a 
null-terminated string and some how managed to include the null termination for 
each character when outputting the converted data.  Maybe they have their 
software package mis-configured in some way, or since they are talking about 
workstation software producing the data, the software package generating the 
data may be ignorant of EBCDIC and the fault may be in what technique they are 
using after-the-fact to either convert the data to EBCDIC or transmit the data 
with conversion.

If at all possible, try to get clarification of exactly what software and 
options they are using to produce the data and exactly what technique and 
options they are using to transmit the data.  If possible, get them to transmit 
via other methods (Email, FTP, etc.) samples of any intermediate files as 
binary data so you can see exactly what data format they are really dealing 
with on their workstation (as opposed to what the client may think he has).  If 
they are really transmitting twice the number of needed bytes, fixing the 
problem at their end would be the better solution.  Perhaps given enough 
background on what they are doing, a solution would become obvious, or you 
would be able to search on-line for a solution if the client lacks the 
technical expertise to do so on their own.

If everything is kosher on their end and the byte doubling is somehow occurring 
just on your receiving system, then hopefully you will have enough to be able 
to recreate and fix the problem on your end.  Just cleaning up bad data after 
the fact will work, but is not as desirable as eliminating the creation of the 
bad data in the first place.

-- Joel C. Ewing,    Bentonville, AR      jcew...@acm.org    

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

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

Re: removing nulls from a file

[McKown, John]

Sounds like the original file is UTF-16. The simpliest thing is to convert it 
to UTF-8 before transferring. But I know that many "clients" are not 
knowledgable enough to do this. If you transfer this into a UNIX file on z/OS, 
then it is rather simple. Use the 'tr' command.

tr -d '\000' output.file

If in a z/OS dataset, you might want to try:

cp -T "//'HLQ.INPUT.FILE'" /dev/fd1 |\
tr -d '/000' |\
cp -T /dev/fd0 "//'HLQ.OUTPUT.FILE'"

I would preallocate the output file to establish the DCB and space parameters. 

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Brad Wissink
> Sent: Thursday, December 29, 2011 9:20 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: removing nulls from a file
> 
> We have a client that is trying to transfer us a file and it 
> is loaded with nulls.  They say that is the way it comes from 
> the purchased software they have on their workstation.  The 
> file has a null character inserted after every character so 
> it looks like this
> 
> 1 12/29/2011   becomes  
> F1004000F100F2006100F200F9006100F200F000F100F100...
> 
> Has anyone seen anything like this before?  Is there a quick 
> and easy way to remove all the nulls?
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

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

Re: Question on adding an SVC routine dynamically to a running system

[Dave Day]

Answering my own question, just for the record.  I just tried it, and there 
is no need to actually have the module in the LPA chain. SVCUPDTE does 
indeed update the SVC table, and the SVC can be executed with no problems.


   --Dave Day
- Original Message - 
From: "Dave Day" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Thursday, December 29, 2011 9:00 AM
Subject: Question on adding an SVC routine dynamically to a running system


   The auth services guide in the chapter on user SVCs, states a type 3 
needs to be in LPA.  Yet the SVCUPDATE will accept, and update the svc 
table, an address in ECSA.  Do I need to add the routine to LPA using 
CSVDYLPA prior to SVCUPDATE?


   --Dave Day

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


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

Re: removing nulls from a file

[Joel C. Ewing]

On 12/29/2011 09:19 AM, Brad Wissink wrote:

We have a client that is trying to transfer us a file and it is loaded with 
nulls.  They say that is the way it comes from the purchased software they have 
on their workstation.  The file has a null character inserted after every 
character so it looks like this

1 12/29/2011   becomes  F1004000F100F2006100F200F9006100F200F000F100F100...

Has anyone seen anything like this before?  Is there a quick and easy way to 
remove all the nulls?



It's almost as if they are using software that somehow mistakenly thinks 
EBCDIC is a two-byte character encoding, or the process for conversion 
to EBCDIC was written by a neophyte programmer who treated each 
character as a null-terminated string and some how managed to include 
the null termination for each character when outputting the converted 
data.  Maybe they have their software package mis-configured in some 
way, or since they are talking about workstation software producing the 
data, the software package generating the data may be ignorant of EBCDIC 
and the fault may be in what technique they are using after-the-fact to 
either convert the data to EBCDIC or transmit the data with conversion.


If at all possible, try to get clarification of exactly what software 
and options they are using to produce the data and exactly what 
technique and options they are using to transmit the data.  If possible, 
get them to transmit via other methods (Email, FTP, etc.) samples of any 
intermediate files as binary data so you can see exactly what data 
format they are really dealing with on their workstation (as opposed to 
what the client may think he has).  If they are really transmitting 
twice the number of needed bytes, fixing the problem at their end would 
be the better solution.  Perhaps given enough background on what they 
are doing, a solution would become obvious, or you would be able to 
search on-line for a solution if the client lacks the technical 
expertise to do so on their own.


If everything is kosher on their end and the byte doubling is somehow 
occurring just on your receiving system, then hopefully you will have 
enough to be able to recreate and fix the problem on your end.  Just 
cleaning up bad data after the fact will work, but is not as desirable 
as eliminating the creation of the bad data in the first place.


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Semiprivileged instructions, part 1

[Steve Comstock]

[Consolidating several responses]

On 12/29/2011 6:57 AM, Peter Relson wrote:

<>


BSG - Branch in Subspace Group
EREG- Extract stacked REGisters (32 bits)
EREGG   - Extract stacked REGisters Grande (64-bits)
ESTA- Extract stacked STAte
LPTEA   - Load Page Table Entry Address <== privileged

  (thanks to Peter Relson for pointing that out, below)

MSTA- Modify stacked STAte
SSAR- Set Secondary ASN
SSAIR   - Set Secondary ASN with Instance
STRAG   - Store Real Address  p
TAR - Test Access p  <== not privileged

  (thanks to Allen Gainsford for pointing that out to me)

TPROT   - Test PROTection p



   ('interesting' in the sense they are not
semiprivileged and the first eight are
not privileged either, but they are
described in the chapter on Control
Instructions: so are they 'general'
instructions? I think not, but it's hard
to say.)



My focus: are these first eight instructions useful
for applications programmers?


BAKR, PR, EREG, EREGG are all part of the original linkage standard for
AR-mode routines, providing a way to preserve the ARs (and GR high halves)
without having to change the caller to provide a large enough save area to
hold everything. AR mode is fully available to applications programmers.

ESTA and MSTA are of primary use to PC target routines so would not be
used by writers of *unauthorized* applications.

The statement that "the first eight are not privileged" seems incorrect.
LPTEA is a privileged operation.

SSAR and SSAIR will not be used by an unauthorized application (they may
be issued but would only be in the "current primary" state rather than
"space switch"). SSAR/SSAIR for space switch are semiprivileged. You would
see these in macro expansions of services entered by non-stacking PC's.

Most applications would not care much about using BSG (this was created to
help cases such as CICS to isolate its transactions from each other).

If you think it important to document which semi-privileged instructions
are available to problem state applications, please submit a readers
comment form asking that this be done. It seems reasonable. It appears at
a glance that all of the semiprivileged instructions in table 5-6 on page
5-28 of PoOp are available, subject to such things as "need a suitable PSW
key mask"  and "not requesting space switch". z/OS does set, for example,
CR0 bit 36 which authorizes various instructions.


[I added TRAP2 and TRAP4 after Martin Truebner pointed out the
 omission]

I have noted a couple of omissions in the PoPs that I will submit
a Readers Comment for; but there also needs to be a place in each
operating system's pub set where it specifies what semiprivileged
instructions are available under that system. Not sure where that
would be for z/OS, but I'll give it some thought.


z/OS itself does not provide support for TRAP2/TRAP4. But some
(authorized) program products do this on their own (a bad decision not to
have this provided by the operating system). They got burned when the
architecture changed incompatibly (incompatible changes in the
architecture are almost never done to problem state programs, but such
changes are something that "we" in the base control program expect to take
care of when they occur). The long and short of it is that you can't use
TRAP2/TRAP4 "on your own" if you are not privileged.

Peter Relson
z/OS Core Technology Design



Thanks for that, Peter.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

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

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

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

Re: removing nulls from a file

[Paul Gilmartin]

On Thu, 29 Dec 2011 10:39:13 -0600, Paul Gilmartin wrote:
>
>What about "tr -d \000"?  (I haven't tried it.)
>
I've now tried it.  Oops; forgot about shell escapes.  It must be:
"tr -d '\000'".

(Easier than assembler or PL/I.)

-- gil

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

Re: removing nulls from a file

[Paul Gilmartin]

On Thu, 29 Dec 2011 09:19:30 -0600, Brad Wissink wrote:

>We have a client that is trying to transfer us a file and it is loaded with 
>nulls.  They say that is the way it comes from the purchased software they 
>have on their workstation.  The file has a null character inserted after every 
>character so it looks like this
>
>1 12/29/2011   becomes  F1004000F100F2006100F200F9006100F200F000F100F100...
>
>Has anyone seen anything like this before?  Is there a quick and easy way to 
>remove all the nulls?
> 
When I simply open a file with vi, it complains about any nulls.  When I
save it, the nulls are gone.

Disclaimer:  I've experienced this behavior on other systems; never
tried it on z/OS

What about "tr -d \000"?  (I haven't tried it.)

I bet perl would be great for that.  John?

-- gil

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

Re: removing nulls from a file

[Elardus Engelbrecht]

Brad Wissink wrote:

>We have a client that is trying to transfer us a file and it is loaded with 
>nulls.  They say that is the way it comes from the purchased software they 
>have on their workstation.  The file has a null character inserted after every 
>character so it looks like this

Are they added before or after transfer?

Show us the code page used and the file in hex BEFORE it is transmitted.

>Is there a quick and easy way to remove all the nulls?

John Gilmore gave you a good reply, but please state also WHAT are you using to 
do the actual transfer?

I assume of course the file is looking 'ok'. If the file is already 'broken' as 
supplied, then John Gilmore's reply is perhaps the way to go.

HTH!

Groete / Greetings
Elardus Engelbrecht

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

Re: removing nulls from a file

[John Gilmore]

On a mainframe a small assembly-language routine that uses a TRTO
instruction to views what you have as a DBCS and translates it into an
SBCS, x'' to x'00', x'0100' to x'01', x'0200' into x'02', etc.,
would do what needs to be done.

Be aware that C and other languages that support C's strings of
"conceptually unlimited length" use nuls to delimit EOS.  The TRTO
table entry for x''==>x'00' is thus very important.

This routine could also be written in PL/I, which has a BIF for
DBCS-to-SBCS translation.

John Gilmore, Ashland, MA 01721 - USA

On 12/29/11, Brad Wissink  wrote:
> We have a client that is trying to transfer us a file and it is loaded with
> nulls.  They say that is the way it comes from the purchased software they
> have on their workstation.  The file has a null character inserted after
> every character so it looks like this
>
> 1 12/29/2011   becomes
> F1004000F100F2006100F200F9006100F200F000F100F100...
>
> Has anyone seen anything like this before?  Is there a quick and easy way to
> remove all the nulls?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Gilmore, Ashland, MA 01721 - USA

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Veilleux, Jon L]

We used to have the root mounted R/W and after it got filled up by uneducated 
users putting files in it we decided to clean it up and make it R/O. It took 
the 'fall back' weekend to give us the time to be able to move all of the c**p 
out of the root on our production systems. I strongly suggest mounting it R/O 
and dealing with the occasional change to R/W to add new directories. 
Jon

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Mark Zelden
Sent: Thursday, December 29, 2011 10:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as read/write?

On Thu, 29 Dec 2011 09:25:34 -0600, Mark Zelden  wrote:


>
>On sysplexes that have shared file systems, I usually put the "directory" file 
>system
>mount points in the sysplex root.   It is already R/W and survives across OS
>upgrades.  So instead of a "one time thing" per OS upgrade, it is a 
>"one time thing" - period.
>
>BTW, the same warning about "junk" in the sysplex root as previous 
>warnings.  Was at a shop with many sysprogs (CICS/DB2/MVS) that had 
>"SU" auth and ended up creating a lot more than just mountpoints in the 
>sysplex root.  Eventually the sysplex root had a space issue
>and cleanup needed to be done.   This was before the newroot
>support was added to z/OS  (but doing the cleanup was the right thing 
>to do anyway).
>

Jon's post reminded me that while the original design / instructions may have 
had the sysplex root mounted as R/W, not all the sysplexes I support have it 
that way now.  Some of them mount it as R/O and it gets changed to
R/W if needed to create a new mount point if needed.   That is rare due
to standards that are in place and it keeps the junk from getting put 
in there.   

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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Veilleux, Jon L]

Shared filesystem using SYSPLEX(YES). z/OS 1.12.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Jousma, David
Sent: Thursday, December 29, 2011 10:27 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as read/write?

When you say "shared filesystems", you are speaking of the sysplex sharing 
option, not simple sharing via MODE(READ).  I was speaking of the simple 
MODE(READ) method.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Veilleux, Jon L
Sent: Thursday, December 29, 2011 10:12 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as read/write?

We have a 10 system sysplex with shared filesystems and we use a REXX exec that 
we can run from TSO or ISHELL to change the mount attribute of the root when we 
need to add a new mountpoint.
It uses the " 'unmount '   m.mnte_fsname   mnt" command to change the
mount attributes.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Jousma, David
Sent: Thursday, December 29, 2011 9:14 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as read/write?

Chmount only works in a single system environment.   WE share those
filesystems READ only among several systems, and this would fail.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
McKown, John
Sent: Thursday, December 29, 2011 8:54 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as read/write?

> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jousma, David
> Sent: Thursday, December 29, 2011 7:27 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS 1.13 - Can the root file system be shared as 
> read/write?
> 
> Cant specifically answer your question.   But in general, I 
> don't like mounting any of the z/OS product ZFS file systems 
> read/write because "junk" tends to collect in them whether by
> accident or on purpose.   We are not doing sysplex sharing, 
> but do mount them all READ only.
> 
> _
> Dave Jousma

That's my plan too. I mount all my "root" filesystems (SYSPLEX, VERSION, & 
SYSTEM) as READ, along with the "product" filesystems as well. If I really need 
to do an update, I use a UNIX shell and "cd" to the proper subdirectory. Then 
do a "chmount -w .". Update the filesystem (update a file or rmdir or mkdir, 
whatever). Then "chmount -r ." again. My .profile adds /usr/sbin to my PATH, 
which makes using chmount easier.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

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: INFO IBM-MAIN This e-mail may contain 
confidential or 

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Mark Zelden]

On Thu, 29 Dec 2011 09:25:34 -0600, Mark Zelden  wrote:


>
>On sysplexes that have shared file systems, I usually put the "directory" file 
>system
>mount points in the sysplex root.   It is already R/W and survives across OS
>upgrades.  So instead of a "one time thing" per OS upgrade, it is a "one time
>thing" - period.
>
>BTW, the same warning about "junk" in the sysplex root as previous
>warnings.  Was at a shop with many sysprogs (CICS/DB2/MVS) that
>had "SU" auth and ended up creating a lot more than just mountpoints
>in the sysplex root.  Eventually the sysplex root had a space issue
>and cleanup needed to be done.   This was before the newroot
>support was added to z/OS  (but doing the cleanup was the right
>thing to do anyway).
>

Jon's post reminded me that while the original design / instructions may have
had the sysplex root mounted as R/W, not all the sysplexes I support have
it that way now.  Some of them mount it as R/O and it gets changed to
R/W if needed to create a new mount point if needed.   That is rare due
to standards that are in place and it keeps the junk from getting put 
in there.   

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

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Mark Zelden]

On Thu, 29 Dec 2011 10:26:45 -0500, Jousma, David  wrote:

>When you say "shared filesystems", you are speaking of the sysplex
>sharing option, not simple sharing via MODE(READ).  I was speaking of
>the simple MODE(READ) method.
>

That is what is being referred to (sysplex sharing).  Along with IBM, I started 
using the words "shared filesystems" most of the time years ago instead 
of "shared HFS" because it covers both HFS and zFS.  

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

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Jousma, David]

When you say "shared filesystems", you are speaking of the sysplex
sharing option, not simple sharing via MODE(READ).  I was speaking of
the simple MODE(READ) method.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Veilleux, Jon L
Sent: Thursday, December 29, 2011 10:12 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as
read/write?

We have a 10 system sysplex with shared filesystems and we use a REXX
exec that we can run from TSO or ISHELL to change the mount attribute of
the root when we need to add a new mountpoint.
It uses the " 'unmount '   m.mnte_fsname   mnt" command to change the
mount attributes.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Jousma, David
Sent: Thursday, December 29, 2011 9:14 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as
read/write?

Chmount only works in a single system environment.   WE share those
filesystems READ only among several systems, and this would fail.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of McKown, John
Sent: Thursday, December 29, 2011 8:54 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as
read/write?

> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jousma, David
> Sent: Thursday, December 29, 2011 7:27 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS 1.13 - Can the root file system be shared as 
> read/write?
> 
> Cant specifically answer your question.   But in general, I 
> don't like mounting any of the z/OS product ZFS file systems 
> read/write because "junk" tends to collect in them whether by
> accident or on purpose.   We are not doing sysplex sharing, 
> but do mount them all READ only.
> 
> _
> Dave Jousma

That's my plan too. I mount all my "root" filesystems (SYSPLEX, VERSION,
& SYSTEM) as READ, along with the "product" filesystems as well. If I
really need to do an update, I use a UNIX shell and "cd" to the proper
subdirectory. Then do a "chmount -w .". Update the filesystem (update a
file or rmdir or mkdir, whatever). Then "chmount -r ." again. My
.profile adds /usr/sbin to my PATH, which makes using chmount easier.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

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: INFO IBM-MAIN
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bam

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Mark Zelden]

On Thu, 29 Dec 2011 09:04:51 -0600, McKown, John 
 wrote:

>That's mainly what I use "chmount" for. I put non-IBM products in the /opt 
>subdirectory. As distributed by IBM, /opt is a symlink to $VERSION/opt. But I 
>didn't like that. There were a few distributed symlinks in this $VERSION 
>subdirectory. I made a new filesystem and temporarily mounted it elsewhere. I 
>then recreated the /opt symlinks in my new filesystem. Then I rm'ed the /opt 
>symlink in the sysplex root and did a mkdir for it. I now have an independent 
>filesystem mounted at /opt. This filesystem is mounted RW. But all that is in 
>it are those symlinks and a bunch of subdirectories which I use as mountpoints 
>for separate filesystems. Said filesystems are usually mounted READ, but a few 
>are actually written to by the vendor products. If I could, I would put the 
>RDWR filesystems under /var/&VENDOR, but that is not alwasy possible. In 
>general, my /opt looks like:
>



On sysplexes that have shared file systems, I usually put the "directory" file 
system
mount points in the sysplex root.   It is already R/W and survives across OS 
upgrades.  So instead of a "one time thing" per OS upgrade, it is a "one time
thing" - period.  

BTW, the same warning about "junk" in the sysplex root as previous
warnings.  Was at a shop with many sysprogs (CICS/DB2/MVS) that
had "SU" auth and ended up creating a lot more than just mountpoints
in the sysplex root.  Eventually the sysplex root had a space issue
and cleanup needed to be done.   This was before the newroot 
support was added to z/OS  (but doing the cleanup was the right
thing to do anyway).

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

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

Re: cpu / machine identification

[Scott Ford]

As A vendor I understand the CPU/serial situation but one has to consider the 
less than honest customers and 'yes' I have experience that also

Sent from my iPad

On Dec 29, 2011, at 10:02 AM, "Pommier, Rex R."  
wrote:

> Brian,
> 
> I see your point, but have a request for you.  Don't get quite so aggressive 
> with the electronic scissors on snipping away the context.  The beginning of 
> your comment below says it all - "That works...".  What's "that"?  Since 
> there have been several comments/points of view made, it would be much easier 
> to leave the comment you are replying to in your reply.
> 
> Not trying to be flippant, mind you.  :-)
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Brian Westerman
> Sent: Wednesday, December 28, 2011 8:02 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: cpu / machine identification
> 
> That works for a site license and I agree with it for that type of license, 
> but what about sites that purchase a single processor license and have 4 
> processors, or a systems programmer that decides that he can fix his 
> "friends" problem by sending a copy of the code to them, or the one that 
> decides to post the code on facebook.  (I reaching with the facebook thing, 
> but hopefully you see my point).
> 
> Brian
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> The information contained in this e-mail may contain confidential and/or 
> privileged information and is intended for the sole use of the intended 
> recipient. If you are not the intended recipient, you are hereby notified 
> that any unauthorized use, disclosure, distribution or copying of this 
> communication is strictly prohibited and that you will be held responsible 
> for any such unauthorized activity, including liability for any resulting 
> damages. As appropriate, such incident(s) may also be reported to law 
> enforcement. If you received this e-mail in error, please reply to sender and 
> destroy or delete the message and any attachments. Thank you.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

removing nulls from a file

[Brad Wissink]

We have a client that is trying to transfer us a file and it is loaded with 
nulls.  They say that is the way it comes from the purchased software they have 
on their workstation.  The file has a null character inserted after every 
character so it looks like this

1 12/29/2011   becomes  F1004000F100F2006100F200F9006100F200F000F100F100...

Has anyone seen anything like this before?  Is there a quick and easy way to 
remove all the nulls?

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Jousma, David]

Yea, it has always been the rule that you can only have a filesystem
mounted RDWR on one system only when not doing sysplex sharing.   This
includes other systems mounted read only.   In other words, cant be
mounted anywhere else in any mode.   

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of McKown, John
Sent: Thursday, December 29, 2011 10:09 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as
read/write?

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jousma, David
> Sent: Thursday, December 29, 2011 8:14 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS 1.13 - Can the root file system be shared 
> as read/write?
> 
> Chmount only works in a single system environment.   WE share those
> filesystems READ only among several systems, and this would fail.

Strange. I'll need to review my use. I have SYSPLEX(YES) on my z/OS 1.12
system. But the other system is currently 1.10 and SYSPLEX(NO). I only
have two systems (tiny shop and shrinking). It will be disappointing to
loose the "chmount" capability when I convert the second system to 1.12
and SYSPLEX(YES).

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

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: INFO IBM-MAIN

Re: Question on adding an SVC routine dynamically to a running system

[Tom Marchant]

On Thu, 29 Dec 2011 09:00:54 -0600, Dave Day wrote:

>The auth services guide in the chapter on user SVCs, states a 
>type 3 needs to be in LPA.  Yet the SVCUPDATE will accept, and 
>update the svc table, an address in ECSA.  Do I need to add the 
>routine to LPA using CSVDYLPA prior to SVCUPDATE?   

Why wouldn't you want to?  It's easier than loading the module 
into CSA.

-- 
Tom Marchant

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Veilleux, Jon L]

We have a 10 system sysplex with shared filesystems and we use a REXX exec that 
we can run from TSO or ISHELL to change the mount attribute of the root when we 
need to add a new mountpoint.
It uses the " 'unmount '   m.mnte_fsname   mnt" command to change the mount 
attributes.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Jousma, David
Sent: Thursday, December 29, 2011 9:14 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as read/write?

Chmount only works in a single system environment.   WE share those
filesystems READ only among several systems, and this would fail.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
McKown, John
Sent: Thursday, December 29, 2011 8:54 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as read/write?

> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jousma, David
> Sent: Thursday, December 29, 2011 7:27 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS 1.13 - Can the root file system be shared as 
> read/write?
> 
> Cant specifically answer your question.   But in general, I 
> don't like mounting any of the z/OS product ZFS file systems 
> read/write because "junk" tends to collect in them whether by
> accident or on purpose.   We are not doing sysplex sharing, 
> but do mount them all READ only.
> 
> _
> Dave Jousma

That's my plan too. I mount all my "root" filesystems (SYSPLEX, VERSION, & 
SYSTEM) as READ, along with the "product" filesystems as well. If I really need 
to do an update, I use a UNIX shell and "cd" to the proper subdirectory. Then 
do a "chmount -w .". Update the filesystem (update a file or rmdir or mkdir, 
whatever). Then "chmount -r ." again. My .profile adds /usr/sbin to my PATH, 
which makes using chmount easier.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

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: INFO IBM-MAIN
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of ITURIEL DO NASCIMENTO NETO
> Sent: Thursday, December 29, 2011 8:17 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: RES: z/OS 1.13 - Can the root file system be shared 
> as read/write?
> 
> John,
> 
> It's good to have a UNIX guru around...
> 
> I wish you all a wonderful New Year.
> 
> 
> Atenciosamente / Regards / Saludos
> 
> Ituriel do Nascimento Neto

I don't know about being a "guru". And another person indicated that "chmount" 
won't work in a sysplex filesystem environment. I've got two systems in my 
basic sysplex, but am only now converting my UNIX to SYSPLEX(YES). So I'll be 
testing that on the 15th of January 2012.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

Question on adding an SVC routine dynamically to a running system

[Dave Day]

The auth services guide in the chapter on user SVCs, states a type 3 needs 
to be in LPA.  Yet the SVCUPDATE will accept, and update the svc table, an 
address in ECSA.  Do I need to add the routine to LPA using CSVDYLPA prior to 
SVCUPDATE?   

--Dave Day

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

Re: cpu / machine identification

[Pommier, Rex R.]

Brian,

I see your point, but have a request for you.  Don't get quite so aggressive 
with the electronic scissors on snipping away the context.  The beginning of 
your comment below says it all - "That works...".  What's "that"?  Since there 
have been several comments/points of view made, it would be much easier to 
leave the comment you are replying to in your reply.

Not trying to be flippant, mind you.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Brian Westerman
Sent: Wednesday, December 28, 2011 8:02 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: cpu / machine identification

That works for a site license and I agree with it for that type of license, but 
what about sites that purchase a single processor license and have 4 
processors, or a systems programmer that decides that he can fix his "friends" 
problem by sending a copy of the code to them, or the one that decides to post 
the code on facebook.  (I reaching with the facebook thing, but hopefully you 
see my point).

Brian

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

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[McKown, John]

That's mainly what I use "chmount" for. I put non-IBM products in the /opt 
subdirectory. As distributed by IBM, /opt is a symlink to $VERSION/opt. But I 
didn't like that. There were a few distributed symlinks in this $VERSION 
subdirectory. I made a new filesystem and temporarily mounted it elsewhere. I 
then recreated the /opt symlinks in my new filesystem. Then I rm'ed the /opt 
symlink in the sysplex root and did a mkdir for it. I now have an independent 
filesystem mounted at /opt. This filesystem is mounted RW. But all that is in 
it are those symlinks and a bunch of subdirectories which I use as mountpoints 
for separate filesystems. Said filesystems are usually mounted READ, but a few 
are actually written to by the vendor products. If I could, I would put the 
RDWR filesystems under /var/&VENDOR, but that is not alwasy possible. In 
general, my /opt looks like:

/opt is a filesystem, mainly mountpoints, RW
/opt/vendor-id is a filesystem, mainly mountpoints, READ
/opt/vendor-id/product is a filesystem for the vendor product, READ or RW as 
needed.

I wish that I could "echo" the above in the /var for RW, but that is to 
difficult because vendors don't do it that way.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

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

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

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of ??? ?? ???
> Sent: Thursday, December 29, 2011 8:09 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS 1.13 - Can the root file system be shared 
> as read/write?
> 
> Thanks everyone.
> I didn't know about the chmount command.
> 
> My main problem was always creating a mount point for product 
> specific file systems. Having a way to make the root file 
> system Read/Write temporarily, is the best solution.
> 
> Gadi
> 
> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Zelden
> Sent: Thursday, December 29, 2011 3:55 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS 1.13 - Can the root file system be shared 
> as read/write?
> 
> On Thu, 29 Dec 2011 15:07:25 +0200, גדי 
> בן אבי  wrote:
> 
> >Hi,
> >
> >We are in the process of installing z/OS 1.13.
> >
> >The migration guide has a section about sharing zfs file 
> systems, but I’m still not clear on this issue.
> >
> >So, can the root file system be shared as read/write?
> >
> >Thanks
> >
> >Gadi
> >
> 
> Any file system can be shared read/write if you want in a 
> shared file system environment.
> If you are not in a shared file system environment (you don't 
> have SYSPLEX(YES) in your BPXPRMxx) then you can't share 
> anything other than READ only.
> 
> However, whether in a shared file system environment or not, 
> why would you want
> the z/OS root mounted anything but read only?   It's an 
> accident waiting to happen
> if you do.  z/OS already gives you a way to dynamically 
> activate maintenance when you can and it doesn't involve 
> writing to the IPLed z/OS unix root.
> 
> Regards,
> 
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at 
> http://expertanswercenter.techtarget.com/
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 
> instructions, send email to lists...@bama.ua.edu with the 
> message: INFO IBM-MAIN
> 
> לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, 
> התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי 
> מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס 
> ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
> המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא 
> משום טיוטה לדיון,
> ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
> 
> 
> Please note that in accordance with Malam's signatory rights, 
> no offer, agreement, concession or representation is binding 
> on the company,
> unless accompanied by a duly signed separate document (or a 
> scanned version thereof), affixed with the company's seal.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jousma, David
> Sent: Thursday, December 29, 2011 8:14 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS 1.13 - Can the root file system be shared 
> as read/write?
> 
> Chmount only works in a single system environment.   WE share those
> filesystems READ only among several systems, and this would fail.

Strange. I'll need to review my use. I have SYSPLEX(YES) on my z/OS 1.12 
system. But the other system is currently 1.10 and SYSPLEX(NO). I only have two 
systems (tiny shop and shrinking). It will be disappointing to loose the 
"chmount" capability when I convert the second system to 1.12 and SYSPLEX(YES).

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Mark Zelden]

On Thu, 29 Dec 2011 16:08:38 +0200, גדי בן 
אבי  wrote:

>Thanks everyone.
>I didn't know about the chmount command.
>
>My main problem was always creating a mount point for product specific file 
>systems. Having a way to make the root file system Read/Write temporarily, is 
>the best solution.
>

The best solution is probably to have a single or a few mount points created
for local requirements and do that to a maintenance root file system and then
the next time you clone / IPL it will be there.   Then on that mount
point you can mount a R/W "directory" zFS (or HFS) and create new 
mount points when needed in that zFS / HFS and mount other
file systems from there.It's a "one time" thing for each OS upgrade
that needs to be done.   I've seen those local mount points / directories
set up with names like "prod" / "test", "tech", "software", and even
names that many shops use for ISV product standards from MVS data
sets - "SYS2" or "SYS3" for example.  

The only thing to watch out for is people who may create things in
that "directory" file system instead of just mount points.  But that
can be controlled with the correct permissions and training of 
others who may work on z/OS unix.

Regards,

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

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Bobbie Justice]

You CAN share it read/write, but do you want to? 

NOT a good idea, as others have said, you will find "junk" collecting in it. 

The root here was made read/write when the previous person did 1.10, but under 
1.12, I made it read-only. 

For a real life example of "junk collecting in the root". 

Our 1.10 read/write root - 128,000 tracks 

Our 1.12 read only root - 48,000 tracks (as it should be). 

Bobbie Jo Justice

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

RES: z/OS 1.13 - Can the root file system be shared as read/write?

[ITURIEL DO NASCIMENTO NETO]

John,

It's good to have a UNIX guru around...

I wish you all a wonderful New Year.


Atenciosamente / Regards / Saludos

Ituriel do Nascimento Neto
BANCO BRADESCO S.A.
4254 / DPCD Engenharia de Software
Sistemas Operacionais Mainframes
Tel: +55 11 4197-2021 R: 22021
Fax: +55 11 4197-2814

-Mensagem original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] Em nome de 
McKown, John
Enviada em: quinta-feira, 29 de dezembro de 2011 11:54
Para: IBM-MAIN@bama.ua.edu
Assunto: Re: z/OS 1.13 - Can the root file system be shared as read/write?

> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jousma, David
> Sent: Thursday, December 29, 2011 7:27 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS 1.13 - Can the root file system be shared
> as read/write?
>
> Cant specifically answer your question.   But in general, I
> don't like mounting any of the z/OS product ZFS file systems
> read/write because "junk" tends to collect in them whether by
> accident or on purpose.   We are not doing sysplex sharing,
> but do mount them all READ only.
>
> _
> Dave Jousma

That's my plan too. I mount all my "root" filesystems (SYSPLEX, VERSION, & 
SYSTEM) as READ, along with the "product" filesystems as well. If I really need 
to do an update, I use a UNIX shell and "cd" to the proper subdirectory. Then 
do a "chmount -w .". Update the filesystem (update a file or rmdir or mkdir, 
whatever). Then "chmount -r ." again. My .profile adds /usr/sbin to my PATH, 
which makes using chmount easier.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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



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

AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) 
a quem é dirigida, podendo conter informação confidencial e/ou legalmente 
privilegiada. Se você não for destinatário desta mensagem, desde já fica 
notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de 
qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. 
Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este 
E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de 
dados, registros ou sistema de controle. Fica desprovida de eficácia e validade 
a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha 
poderes de representação. 
LEGAL ADVICE...This message is exclusively destined for the people to whom 
it is directed, and it can bear private and/or legally exceptional information. 
If you are not addressee of this message, since now you are advised to not 
release, copy, distribute, check or, otherwise, use the information contained 
in this message, because it is illegal. If you received this message by 
mistake, we ask you to return this email, making possible, as soon as possible, 
the elimination of its contents of your database, registrations or controls 
system. The message that bears any mandatory links, issued by someone who has 
no representation powers, shall be null or void.

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

Wish all a very Happy and prosperous new Year

[amit]

As we move towards the break of a New Year, i wish all of you and your
loved ones,all the Success, Happiness and Prosperity with moments to
Cherish all year round.
A personal note of Thanks for your support and Knowledge Share. its been a
pleasure and fun to get challenged and share a common love for a System as
we do!..

Hope to be in touch and Share the times with you All.

Best Regards,
Amit

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Jousma, David]

Chmount only works in a single system environment.   WE share those
filesystems READ only among several systems, and this would fail.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of McKown, John
Sent: Thursday, December 29, 2011 8:54 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as
read/write?

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jousma, David
> Sent: Thursday, December 29, 2011 7:27 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS 1.13 - Can the root file system be shared 
> as read/write?
> 
> Cant specifically answer your question.   But in general, I 
> don't like mounting any of the z/OS product ZFS file systems 
> read/write because "junk" tends to collect in them whether by 
> accident or on purpose.   We are not doing sysplex sharing, 
> but do mount them all READ only.
> 
> _
> Dave Jousma

That's my plan too. I mount all my "root" filesystems (SYSPLEX, VERSION,
& SYSTEM) as READ, along with the "product" filesystems as well. If I
really need to do an update, I use a UNIX shell and "cd" to the proper
subdirectory. Then do a "chmount -w .". Update the filesystem (update a
file or rmdir or mkdir, whatever). Then "chmount -r ." again. My
.profile adds /usr/sbin to my PATH, which makes using chmount easier.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

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: INFO IBM-MAIN

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[גדי בן אבי]

Thanks everyone.
I didn't know about the chmount command.

My main problem was always creating a mount point for product specific file 
systems. Having a way to make the root file system Read/Write temporarily, is 
the best solution.

Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Mark Zelden
Sent: Thursday, December 29, 2011 3:55 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.13 - Can the root file system be shared as read/write?

On Thu, 29 Dec 2011 15:07:25 +0200, גדי בן 
אבי  wrote:

>Hi,
>
>We are in the process of installing z/OS 1.13.
>
>The migration guide has a section about sharing zfs file systems, but I’m 
>still not clear on this issue.
>
>So, can the root file system be shared as read/write?
>
>Thanks
>
>Gadi
>

Any file system can be shared read/write if you want in a shared file system 
environment.
If you are not in a shared file system environment (you don't have SYSPLEX(YES) 
in your BPXPRMxx) then you can't share anything other than READ only.

However, whether in a shared file system environment or not, why would you want
the z/OS root mounted anything but read only?   It's an accident waiting to 
happen
if you do.  z/OS already gives you a way to dynamically activate maintenance 
when you can and it doesn't involve writing to the IPLed z/OS unix root.

Regards,

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

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

לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון,
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company,
unless accompanied by a duly signed separate document (or a scanned version 
thereof), affixed with the company's seal.

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Mark Zelden]

On Thu, 29 Dec 2011 15:07:25 +0200, גדי בן 
אבי  wrote:

>Hi,
>
>We are in the process of installing z/OS 1.13.
>
>The migration guide has a section about sharing zfs file systems, but I’m 
>still not clear on this issue.
>
>So, can the root file system be shared as read/write?
>
>Thanks
>
>Gadi
>

Any file system can be shared read/write if you want in a shared file system 
environment.  
If you are not in a shared file system environment (you don't have SYSPLEX(YES) 
in 
your BPXPRMxx) then you can't share anything other than READ only.

However, whether in a shared file system environment or not, why would you want
the z/OS root mounted anything but read only?   It's an accident waiting to 
happen
if you do.  z/OS already gives you a way to dynamically activate maintenance 
when you can and it doesn't involve writing to the IPLed z/OS unix root.

Regards,

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

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

Re: PCOMM & access to workstation file system

[Tom Marchant]

On Thu, 29 Dec 2011 12:43:27 +0200, Itschak Mugzach wrote:

>Surprise! I know what WSA is. Would you believe that? As I wrote in
>previous mails, my interest is not in working in a client server mode, 

WSA does much more useful things (IMO) than allow you to work in 
client server mode.  I use it mostly for file transfer, but have played 
with its ability to edit PC files using the ISPF editor.  Dave Salt might 
step in to list other capabilities of the connection.

>but
>in a way that will enables me to share Mainframe TSO and PC file system
>using the fact that PCOMM is running on the workstation. 

PCOMM running on the workstation has nothing to do with it.  You 
could, for example, run your emulator (which doesn't have to be 
PCOMM, BTW) on one computer and WSA on another, then use WSA 
to access the files on that other computer.  Or you could use a real 
3270 and access the files on your workstation using WSA.

>I know how to do
>this using VBSCRIPTS, but I want to do it directly from PCOMM. For example,
>if you define an input field on a panel, specify a URL and click on it, you
>will be passed to a browser. 

That is purely a function of PCOMM.  TSO has nothing to do with it, 
though it may have provided the URL.

>The idea is to access the file system instead
>of leaving PCOMM.

It sounds like you are asking to have an emulator that also does 
other things.

-- 
Tom Marchant

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Veilleux, Jon L]

Yes, it CAN be shared R/W but it SHOULDN'T be shared R/W. You will find that 
any R/W zFS will end up having garbage written to it. Also, any zFS that 
contains vendor-distributed executables should be in a R/O zFS for security and 
reliability. You don't want to allow anyone to either accidentally or 
purposefully update vendor code which may be running with a high level of 
access.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
??? ?? ???
Sent: Thursday, December 29, 2011 8:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: z/OS 1.13 - Can the root file system be shared as read/write?

Hi,

We are in the process of installing z/OS 1.13.

The migration guide has a section about sharing zfs file systems, but I’m still 
not clear on this issue.

So, can the root file system be shared as read/write?

Thanks

Gadi


לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, 
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company, unless 
accompanied by a duly signed separate document (or a scanned version thereof), 
affixed with the company's seal.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

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

Re: PCOMM & access to workstation file system

[Tom Marchant]

On Wed, 28 Dec 2011 10:28:54 -0500, Shmuel Metz (Seymour J.) wrote:

>You can't use the WSA until it's installed.

Yes, I know.  The workstation download dialog gives three ways 
to install the WSA.
1. FTP (requires workstation FTP server)
2. ISPF C/S (requires workstation connection)
3. Manual

The OP mentioned that the help panels says, "You can also choose 
to have ISPF create the directory on your
workstation before copying the file." 
He asked how it does that.  I listed the ways that it can.  I don't 
remember ever having to download a newer WSA, so that one isn't 
particularly interesting.

-- 
Tom Marchant

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

Re: Semiprivileged instructions, part 1

[Peter Relson]

<>

>BSG - Branch in Subspace Group
>EREG- Extract stacked REGisters (32 bits)
>EREGG   - Extract stacked REGisters Grande (64-bits)
>ESTA- Extract stacked STAte
>LPTEA   - Load Page Table Entry Address
>MSTA- Modify stacked STAte
>SSAR- Set Secondary ASN
>SSAIR   - Set Secondary ASN with Instance
>STRAG   - Store Real Address  p
>TAR - Test Access p
>TPROT   - Test PROTection p

>   ('interesting' in the sense they are not
>semiprivileged and the first eight are
>not privileged either, but they are
>described in the chapter on Control
>Instructions: so are they 'general'
>instructions? I think not, but it's hard
>to say.)

>My focus: are these first eight instructions useful
>for applications programmers?

BAKR, PR, EREG, EREGG are all part of the original linkage standard for 
AR-mode routines, providing a way to preserve the ARs (and GR high halves) 
without having to change the caller to provide a large enough save area to 
hold everything. AR mode is fully available to applications programmers. 

ESTA and MSTA are of primary use to PC target routines so would not be 
used by writers of *unauthorized* applications.

The statement that "the first eight are not privileged" seems incorrect. 
LPTEA is a privileged operation.

SSAR and SSAIR will not be used by an unauthorized application (they may 
be issued but would only be in the "current primary" state rather than 
"space switch"). SSAR/SSAIR for space switch are semiprivileged. You would 
see these in macro expansions of services entered by non-stacking PC's. 

Most applications would not care much about using BSG (this was created to 
help cases such as CICS to isolate its transactions from each other). 

If you think it important to document which semi-privileged instructions 
are available to problem state applications, please submit a readers 
comment form asking that this be done. It seems reasonable. It appears at 
a glance that all of the semiprivileged instructions in table 5-6 on page 
5-28 of PoOp are available, subject to such things as "need a suitable PSW 
key mask"  and "not requesting space switch". z/OS does set, for example, 
CR0 bit 36 which authorizes various instructions. 

z/OS itself does not provide support for TRAP2/TRAP4. But some 
(authorized) program products do this on their own (a bad decision not to 
have this provided by the operating system). They got burned when the 
architecture changed incompatibly (incompatible changes in the 
architecture are almost never done to problem state programs, but such 
changes are something that "we" in the base control program expect to take 
care of when they occur). The long and short of it is that you can't use 
TRAP2/TRAP4 "on your own" if you are not privileged.

Peter Relson
z/OS Core Technology Design

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

Re: Clarification on Sysres Volumes(RMF)

[Mark Zelden]

On Thu, 29 Dec 2011 12:39:44 +0530, jagadishan perumal  
wrote:

>Hi,
>
>I was examining the RMF delay report where below is the report :
>
>   Speed of 100 = Maximum, 0 = Stopped Average CPU Util:
>19 %
>Name   Users Active  Speed  Name   Users Active
>Speed
>*SYSTEM  203 58  8  *DEV 107
>54  8
>ALL TSO  119 52  5  *MASTER*   1  0
>56
>ALL STC   74  3
>40
>ALL BATCH  8  4
>21
>ALL ASCH Not
>avail
>ALL OMVS   2  0No
>work
>*PROC129  3
>7
>
>
>-- Exceptions
>-
>Name   ReasonCritical val. Possible cause or
>action
>DOV0053DEV -Z18RS193.0 % delay May be reserved by another
>system.
>DOV0061DEV -Z18RS192.0 % delay May be reserved by another
>system.
>DOV0065DEV -Z18RS191.0 % delay May be reserved by another
>system.
>
>The above exceptions shows lot of device contention due to which often we
>are facing a session hang. Also, Device display shows the status as
>BSY(busy). Could anyone please throw some light on the above issue.
>
>Jags
>


Are you in a shared DASD environment?   If not, is there a test / sandbox
LPAR up accessing that volume?   Even so, I've shared / share the sysres
between different monoplex systems without any problems because it
is "read only" and much of the access comes from the LNKLST / LLA / VLF
which means there is also no I/O contention.

If you are sharing it in some way, it looks like there is a data set on that 
volume
that is subject to RESERVE. You can check what it is from the other system(s) 
using RMF post processor reports if you have the option turned on or look
real time via "TSO RMFMON" SENQR option (PF9) and keep hitting
enter until you see it, or use the RMF III ENQR command.   

The big problem here isn't that there is a RESERVE, it is that going by 
the volser name this looks like your sysres volume or part of the sysres
set.   There should be no data sets on your sysres subject to RESERVE
(except the VTOC and VVDS if you have your zFS files on there).  


Regards,

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

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jousma, David
> Sent: Thursday, December 29, 2011 7:27 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS 1.13 - Can the root file system be shared 
> as read/write?
> 
> Cant specifically answer your question.   But in general, I 
> don't like mounting any of the z/OS product ZFS file systems 
> read/write because "junk" tends to collect in them whether by 
> accident or on purpose.   We are not doing sysplex sharing, 
> but do mount them all READ only.
> 
> _
> Dave Jousma

That's my plan too. I mount all my "root" filesystems (SYSPLEX, VERSION, & 
SYSTEM) as READ, along with the "product" filesystems as well. If I really need 
to do an update, I use a UNIX shell and "cd" to the proper subdirectory. Then 
do a "chmount -w .". Update the filesystem (update a file or rmdir or mkdir, 
whatever). Then "chmount -r ." again. My .profile adds /usr/sbin to my PATH, 
which makes using chmount easier.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

Re: Regarding LE control blocks

[Binyamin Dissen]

It is at a customer.  But why would the older enclave, FOO, be cleaning up
COBOL when COBOL did not run in that enclave?

On Thu, 29 Dec 2011 09:19:12 +1100 Wayne Bickerdike  wrote:

:>Just a guess, because you have OPTIONS(MAIN) on the PL/I?

:>Have you tried with PL/I not main?

:>On Thu, Dec 29, 2011 at 8:51 AM, Binyamin Dissen
:> wrote:
:>> The environment:

:>> Assembler LE main creates enclave FOO.

:>> It calls an Enterprise PL/I OPTIONS(MAIN) which creates enclave BAR

:>> PL/I program calls Enterprise COBOL.

:>> Enclave BAR ends.

:>> Enclave FOO abends during termination attempting to clean up COBOL data that
:>> was already freed during BAR termination - cleaning up COBOL.

:>> Why would FOO be trying to do this?

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: z/OS 1.13 - Can the root file system be shared as read/write?

[Jousma, David]

Cant specifically answer your question.   But in general, I don’t like mounting 
any of the z/OS product ZFS file systems read/write because "junk" tends to 
collect in them whether by accident or on purpose.   We are not doing sysplex 
sharing, but do mount them all READ only.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
??? ?? ???
Sent: Thursday, December 29, 2011 8:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: z/OS 1.13 - Can the root file system be shared as read/write?

Hi,

We are in the process of installing z/OS 1.13.

The migration guide has a section about sharing zfs file systems, but I’m still 
not clear on this issue.

So, can the root file system be shared as read/write?

Thanks

Gadi


לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון,
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company,
unless accompanied by a duly signed separate document (or a scanned version 
thereof), affixed with the company's seal.

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

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: INFO IBM-MAIN

z/OS 1.13 - Can the root file system be shared as read/write?

[גדי בן אבי]

Hi,

We are in the process of installing z/OS 1.13.

The migration guide has a section about sharing zfs file systems, but I’m still 
not clear on this issue.

So, can the root file system be shared as read/write?

Thanks

Gadi


לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון,
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company,
unless accompanied by a duly signed separate document (or a scanned version 
thereof), affixed with the company's seal.

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

Re: PCOMM & access to workstation file system

[Itschak Mugzach]

Hi Shmuel,

Surprise! I know what WSA is. Would you believe that? As I wrote in
previous mails, my interest is not in working in a client server mode, but
in a way that will enables me to share Mainframe TSO and PC file system
using the fact that PCOMM is running on the workstation. I know how to do
this using VBSCRIPTS, but I want to do it directly from PCOMM. For example,
if you define an input field on a panel, specify a URL and click on it, you
will be passed to a browser. The idea is to access the file system instead
of leaving PCOMM.

ITschak

On Thu, Dec 29, 2011 at 12:07 PM, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:

> In
> ,
> on 12/29/2011
>at 08:40 AM, Itschak Mugzach  said:
>
> >I don't want to install WSA.
> Then you don't know what it is.
>
> >I am interesting in the technique used to let
> >ISPF to communicate with the machine PCOMM runs on.
>
> The techique is to connect to WSA.
>
> --
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Hiperbatch still supported ?

[Daniel Cremieux]

Many thanks Radoslaw !

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

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In <7026723933836234.wa.brianwestermansyzygyinc@bama.ua.edu>, on
12/28/2011
   at 07:58 PM, Brian Westerman  said:

>I really don't think any site would readily agree to have their site
>"audited" by a software company for compliance.

Why not?

>After the silence, the sale would disappear. :)

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

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

Re: PCOMM & access to workstation file system

[Shmuel Metz (Seymour J.)]

In
,
on 12/29/2011
   at 08:40 AM, Itschak Mugzach  said:

>I don't want to install WSA.
Then you don't know what it is.

>I am interesting in the technique used to let
>ISPF to communicate with the machine PCOMM runs on.

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

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

Count your fingers ... was cpu / machine identification

[Shane]

> I know of people that don't lock their cars ...

I never lock mine, and leave the windows down a few inches.
My German Shepherd needs fresh air in this climate. Anyone stupid
enough to put their hand in deserves all they get. The mutt is friendly
but slightly territorial.
Never had anything nicked, although am often met by people who want
to pat the fella.

Shane ...

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

SV: cpu / machine identification

[Thomas Berg]

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
> Brian Westerman
> Skickat: den 29 december 2011 03:10
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: cpu / machine identification
> 
... 
> I'm sure you lock your car, why do that if you have the only key?  :)
> 
> Brian

I know of people that don't lock their cars - to avoid damage if someone wants 
to get into the car. 
 

 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

 

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