2007 ServerWatch Product Excellence Awards

[Timothy Sipples]

ServerWatch is accepting votes in several categories through May 25th for
their annual Product Excellence Awards.  You can get to the voting link
from ServerWatch.com or go to the voting page directly:

http://cp.jupiterweb.com/index.php/3681_default

Strangely z/VM isn't on the list for virtualization -- don't know how they
missed that one -- but System z9 is on the list in the "High-End Server"
category.

One vote per person, please.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]

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

Re: Finally get to go from os390 2.10 to zOS 1.8

[Ed Gould]

On May 6, 2007, at 10:57 PM, Brian Westerman wrote:
---SNIP--



There will be exits that need to be re-written, but even if you had  
stayed
within the N+/-2 scheme, you still would have run into the issue a  
some
point.  Sites that are fairly vanilla (home grown and exit-wise),  
don't
really have much to fear from making the big jumps.  There are a  
lot of

people who got bitten just from the JES2 changes from z/OS 1.6 to 1.7.

So, while there will be issues that need to be addressed, they are  
the same
ones that would have to be addressed if the original thread creator  
was to
jump in multiple steps, (OS/390 to z/OS 1.4, then 1.6 then 1.8),  
they just
would have had a great deal of extra conversion work that might  
have masked
the basic changes that they needed to make to their own "home  
grown" code.


I'm not into making people jump through hoops to get from point A  
to Z, (get
it?), if I can get them there directly, why force them to go  
through B, C D,

etc. when all they will really get from it is extra work?

==SNIP

I used to work at a "vanilla" shop a while ago. We had an occasion to  
put on several years of maintenance at one time because of management  
sitting on their collective asses and not upgrading the computer.


As you say exits have to be looked at (re-written) etc and those were  
the types of things that we ran into and all had been anticipated.  
SInce the exits were simple it was pretty much a stream lined  
operation. I think the upgrade of OEM products proved to be a PITA  
more than the exits. One of larger issues we had with OEM is that at  
that time the (some) didn't have a clue as to what release of their  
software would run with each IBM release. I gave the project to a jr  
system programmer and after a week he came back with a report that  
made my spine cringle. I then decided to do the project myself and  
came away almost crying as the vendors just DID NOT have a clue. I  
had to set up a conference call with each one of the vendors and make  
sure that people that were supposed to be there on the conference  
line were there. This was approximately 10 years ago (IIRC before the  
N+2 which I think all the vendors loved as they could get their arms  
around it).


Having said that we tested everything that we could production (not  
every job just a cross section) and everything worked as expected.  
The switch over happened and almost zero issues for the first say 4  
hours then one job JCL'd then 2 then 3 then 4 after about 30 minutes  
we had 8 jobs that had jcl'd. Out of 200+ jobs we had 8 jobs that  
failed. It turned out that there was a JCL DD DLM= that did us in Jes  
2 changed the rules and it wasn'[t terribly clear if it was the  
converter interpreter  or JES. I sat down and skimmed the cover  
letters and found out that JES 2 was the "culprit". I was able to  
convey to the production control people what had to be looked for and  
how to change it.


I cannot blame OEM I can't blame exits just JES and why there didn't  
flag the ptf as needing to be special handling.


In my case it was IBM PTF and OEM vendor(s) that did not understand  
the IBM level OS issue.


Ed

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

Re: Finally get to go from os390 2.10 to zOS 1.8

[Brian Westerman]

That's true, but then there are a lot of old systems that didn't understand
things anyway. :)

In my experience, the biggest drawbacks to conversion have always been the
sites home-grown code.  There is still a lot of code that probably should
have been updated years ago, but never was, and when you make a big jump,
you will surely find them, but so long as you are careful, those issues
shouldn't be too difficult to overcome.

There will be exits that need to be re-written, but even if you had stayed
within the N+/-2 scheme, you still would have run into the issue a some
point.  Sites that are fairly vanilla (home grown and exit-wise), don't
really have much to fear from making the big jumps.  There are a lot of
people who got bitten just from the JES2 changes from z/OS 1.6 to 1.7.  

So, while there will be issues that need to be addressed, they are the same
ones that would have to be addressed if the original thread creator was to
jump in multiple steps, (OS/390 to z/OS 1.4, then 1.6 then 1.8), they just
would have had a great deal of extra conversion work that might have masked
the basic changes that they needed to make to their own "home grown" code.

I'm not into making people jump through hoops to get from point A to Z, (get
it?), if I can get them there directly, why force them to go through B, C D,
etc. when all they will really get from it is extra work?

Brian

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

The Register 100K people to be vaporized by IBM

[Ed Gould]

http://www.theregister.co.uk/2007/05/05/ibm_cringely_100k/

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

Re: WLM and TCB's priority

[Ted MacNEIL]

>When a dispatchable unit is placed on the Work Element Block (WEB) the 
>priority is a combination of A/S priority and Task Priority. For SRBs its A/S 
>priority plus the SRB Type (Global or Local) which yields a
higher priority than for tasks.


Sorry, I don't speak technobabble.

I KNOW what happens, and your response is gibberish.

CICS is raised in priority, when a task is having a problem, but a rising wave 
lifts all boats.
-
Too busy driving to stop for gas!  

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

Re: WLM and TCB's priority

[Bob Shannon]

When a dispatchable unit is placed on the Work Element Block (WEB) the
priority is a combination of A/S priority and Task Priority. For SRBs
its A/S priority plus the SRB Type (Global or Local) which yields a
higher priority than for tasks.

Bob Shannon
Rocket Software

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

WLM and TCB's priority

[Schiradin,Roland HG-Dir itb-db/dc]

Does WLM honor TCB priority or just ASID priority?
For CICS even of response times goals it just take care of the ASID and not for 
the TCB. 
Regardless of the QR TCB or L8/L9 TCB. This means any task running on the L8 
TCB 
could cause a higher prio for the CICS Asid regardless of all other perhaps 
"low prio" task
running on the QR TCB or other L8/L9 TCB.

How does it work for enclave (e.g. DB2 DDF) running in the DIST ASID?
The same or does WLM honor the TCB dispatch prio?



Roland Schiradin
ALTE LEIPZIGER Lebensversicherung auf Gegenseitigkeit
IT Betrieb - DB/DC
Tel. (06171) 66-4095, Fax (06171) 66-7500-4095
mailto:[EMAIL PROTECTED]
http://www.Alte-Leipziger.de

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

Re: time() in z/OS XL C with LP64 (AMODE 64) --> bug?

[Don Poitras]

In article <[EMAIL PROTECTED]> you wrote:
> Using the C compiler of z/OS XL C/C++ V1.8:

> In AMODE 31, calling time() to retieve the current calendar time works fine.

> However, when compiling with the LP64 option, the compilation and binding 
> are OK, but the program execution results in an ABEND U4087 with reason code 
> 7, while running LE-module CELQLIB.
> ABEND U4087 indicates that an error during error processing (i.e. a 
> recursive error) was detected.

> I wonder if someone else experienced the same problem.
> Is it a (documented) bug?

> TIA for the feedback.

Works for me:

/u/sasdtp: >cat time.c
#define __Posix1a
#include 
#include 
#include 
#include 

int main()
{
time_t theTime;
struct tm *lcltime;
char msg_str[80];

theTime = time(NULL);
lcltime = localtime(&theTime);
strftime(msg_str, 80, "Local time is %m.%d.%Y %H:%M:%S",lcltime);
printf("%.80s\n", msg_str);

return 0;
}
/u/sasdtp: >c89 -Wc,LP64 -Wl,LP64 -o time time.c   
/u/sasdtp: >./time
Local time is 05.06.2007 17:35:33


> Michel Castelein

> --
> Michel Castelein - Arcis Services
> MVS-OS/390-z/OS system engineer & instructor
> arcis[at]advalvas[dot]be
> http://www.geocities.com/michelcastelein/ 



-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
[EMAIL PROTECTED]   (919) 531-5637Cary, NC 27513

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

SHOWzOS 715 fix

[Schiradin,Roland HG-Dir itb-db/dc]

Sorry for this posting, but since last fryday a new SHOWzOS 715 is available 
(www.cbttape.org/updates.htm)
This version will no longer abend with U4088 RC63 among other S0C4 on z/OS R8. 

However large CF installation still get IXLMG RC=12 RSN=0102080E. I have fixed 
this.
Feel free to contact me via mail if you seen this msg and require the fix. 

Another issue is the UNICODE display with z/OS R8. Seems IBM made some changes
in this area after the latest z/OS R8 beta. I'm working on this so please 
contact me offline. 

I'm moving forword and work on SHOWzOS 716. You can reach me always at 
mailto:[EMAIL PROTECTED]

In case of abends please don't email DUMPs unless I'm asking for it. Just the 
register and psw would
nice. Usually I'll email some debug code.  

All the best
Roland

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

Re: Lean and Mean: 150,000 U.S. layoffs for IBM?

[Ted MacNEIL]

>AMEN!

But, gullible!
There is no way 150,000 are being laid off in the US!

The issue may be real, but (in this case) the facts can't be!
-
Too busy driving to stop for gas!  

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

Re: Lean and Mean: 150,000 U.S. layoffs for IBM?

[Bill Wilkie]

AMEN!

Bill



From: Robert Justice <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Lean and Mean: 150,000 U.S. layoffs for IBM?
Date: Fri, 4 May 2007 20:15:55 -0400

I just wonder how long it's going to be before people finally WAKE UP in 
this country and quit putting up with the offshoring, the outsourcing, the 
"free trade" b.s, the H1B visa SCAM and completely idiotic ceo 
compensation. .


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


_
Download Messenger. Join the i’m Initiative. Help make a difference today. 
http://im.live.com/messenger/im/home/?source=TAGHM_APR07


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

Re: Mainframe Data Center Permanant Shutdown Procedure Needed

[Eric Bielefeld]

Radoslaw,

I think that all the data that P&H thought they would need, they 
converted and FTP'd to the datacenter in Pennsylvania.  The tapes that 
they saved were data that they might need at some time.  So far, I 
don't know if they have needed to go back and use any of the data or 
not.  

Personally, I wanted to do full volume dumps on all packs.  Then, if 3 
years from now, they desperately needed something, they could rent a 
hot site and load enough stuff to pull off anything they needed.  Very 
expensive, but sometimes that is required.  They chose to not keep 
anything from system pack backups, so there would be no way to reload 
the system and extract any data from it.  

Eric Bielefeld

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of R.S.
> Sent: Sunday, May 06, 2007 1:27 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Mainframe Data Center Permanant Shutdown Procedure Needed
> 
> Eric Bielefeld wrote:
> > One area that we had a lot of debate on at P&H Mining was how to 
access
> > tapes that were saved.  They saved a lot of 3490 carts, but had no 
way
> of
> > reading them.  They thought of buying a 3490 drive and software to
> convert
> > the data to ASCII, but as far as I know, they didn't buy anything.  
I
> think that
> > would have cost about $10K.
> [...]
> That's the issue I don't understand/accept. Someone should know *what
> data* should be kept for what time and then ask what media the data
> occupy. After that analysis, all needed, or "possibly needed" data can
> be read to another media, like DVD, the rest can be safely erased or
> destroyed with the media. Sometimes legal requirements makes the
> migration too hard (i.e. custmer of a bank can request his account's
> history), so it's easier to simply keep the old system just for
> historical data retrieval until the period set by the law expires.
> There are many other ways, but keeping tapes just to keep them doesn't
> sound reasonable.
> My $0.02
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 

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

Re: ftp of exclusively used Member

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 05/04/2007
   at 07:38 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>That may be less risky than you suggest. 

Or more risky than I suggested :-(

>We do share PDSEs across sysplexes,

It's not my dog ;-)
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Article for z/Journal

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 05/04/2007
   at 11:58 PM, Ed Finnell <[EMAIL PROTECTED]> said:

>Folks prohibited from participating in the list for legal or  company
>policy  would otherwise partake of an anonymous high quality survey.

There's no guaranty of high quality, and no reason to expect unbiased
sampling. You seem to be begging the question, assuming the things
that you should be demonstrating.

>Better data,

Or worse data.

>better conclusions,

Or worse.

>higher credibility.

Or worse.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3480/3490 Cart BPI

[Mike Baldwin]

Tom wrote:
>Not parity.  3480 is 18 tracks.  That's 16 data bits and two parity bits.

Although 8 bit bytes are represented by 9 bit patterns,
data bytes are recorded in frames, that are grouped into clusters.

4 tracks are reserved for redundancy check bytes.

Up to 14 tracks contain data bytes, but sometimes contain
padding, residual, or CRC bytes.

For the "control" blocks, tracks are also divided into 6 zones.

This info is in the ECMA standard.

Regards,
Mike Baldwin
Cartagena Software Ltd.
www.cartagena.com

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

Re: Mainframe Data Center Permanant Shutdown Procedure Needed

[R.S.]

Eric Bielefeld wrote:
One area that we had a lot of debate on at P&H Mining was how to access 
tapes that were saved.  They saved a lot of 3490 carts, but had no way of 
reading them.  They thought of buying a 3490 drive and software to convert 
the data to ASCII, but as far as I know, they didn't buy anything.  I think that 
would have cost about $10K.  

[...]
That's the issue I don't understand/accept. Someone should know *what 
data* should be kept for what time and then ask what media the data 
occupy. After that analysis, all needed, or "possibly needed" data can 
be read to another media, like DVD, the rest can be safely erased or 
destroyed with the media. Sometimes legal requirements makes the 
migration too hard (i.e. custmer of a bank can request his account's 
history), so it's easier to simply keep the old system just for 
historical data retrieval until the period set by the law expires.
There are many other ways, but keeping tapes just to keep them doesn't 
sound reasonable.

My $0.02

--
Radoslaw Skorupka
Lodz, Poland


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

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

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci 
opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 
r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 
z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

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

Re: How difficult would it be for a SYSPROG ? (was RE: Mainframe Data Center Permanant Shutdown Procedure Needed)

[Robert Justice]

Actually I think 3-4 days is more like it. 




Anthony Saul Babonas wrote:
[...]

About 10 years ago I took a couple of classes in Novell and deduced that
anyone with zOS sysprog background could
become a guru in 2-3 days.  


You were wrong. Deeply wrong.
However I can feel some affinity between MVS and NetWare.



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

Re: How difficult would it be for a SYSPROG ? (was RE: Mainframe Data Center Permanant Shutdown Procedure Needed)

[R.S.]

Anthony Saul Babonas wrote:
[...]

About 10 years ago I took a couple of classes in Novell and deduced that
anyone with zOS sysprog background could
become a guru in 2-3 days.  


You were wrong. Deeply wrong.
However I can feel some affinity between MVS and NetWare.

--
Radoslaw Skorupka
Lodz, Poland
former NetWare specialist


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

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

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci 
opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 
r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 
z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

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

Re: ftp of exclusively used Member

[Paul Gilmartin]

(I omitted an important point):

In a recent note, Kenneth E Tomiak said:

> Content-Type: text/plain
> 
> Your testing shows that another user can not get the same member you can
> get. How is that different than ftp can not get the same member you can get.
> It is not. Since you have the exclusive lock you can get it as many times as
> you can nest view, browse or start more sessions. You have it, you have it.
> 
Quite the contrary; my testing shows that another user _can_ "get" (in the
sense of read or browse) the same member while I hold the SPFEDIT ENQ.  Why
should FTP's GET behave any differently?  Again, the sequence of updating the
directory entry of a PDS assures that FTP, like ISPF BROWSE, won't "get" a
partially updated member.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: ftp of exclusively used Member

[Paul Gilmartin]

In a recent note, Kenneth E Tomiak said:

> Subject:  Re: ftp of exclusively used Member
> 
> ISPF is smart enough to know what ISPF is doing so you can get away with
> browsing and viewing the contents of an ISPF member being edited. Right up
> until they perform a save. If you were able to try to view the member while
> the pds was being updated you would have a problem. Obviously, you would
> not be able to swap your screen and try to view the same member while you
> were also doing a save. But another task not following the rules could. The
> rules are there for data integrity.
> 
Those rules are described in:

Title: z/OS V1R7.0 ISPF Planning and Customizing
Document Number: GC34-4814-04

A.0   Appendix A.  ISPF Enqueue Processing for Data Integrity
A.3   Member Name Enqueue

They are available for other tasks to use.  Admittedly:

o I do not know that they are formally supported as Programming Interfaces.

o A prior section states that non-ISPF tasks must use exclusive SYSDSN ENQ
  when updating a data set (but it makes no such statement about reading).

o There was a documented change in the convention several releases ago.

> The problem with a PDS, not PDSE, comes when an ISPF task and a non-ISPF
> task try to update the same PDS. PDS, not just member. I did some work for a
> financial firm that every few months complained their batch job was not
> working. Turned out they were using DISP=SHR to put a member in a PDS their
> developers were regularly using. Every now and then, in that tiny window of
> opportunity, the batch job would try to update the pds and the same moment
> a develoepr was trying to save their work. During the process to create the
> member they both get the same TTR and start writing their data. Whoever is
> slower is the winner because they wrote last.
> 
When I need to do that, I use ISPF LM services in batch, as that financial
firm should also have done.

> The RFC for FTP does not include trying to work with the ISPF enqueues.
> Therefore, exclusive use to a non-ISPF task means it is busy, try again later.
> 
Red herring.  I also doubt (I haven't checked) that RFC 959 mentions
trying to work with z/OS SYSDSN enqueues.

> Funny you disagree, look at any operating system and any database and you
> find some form of a locking mechanism has been built to prevent access whlie
> it is being updated. And yes, they have record level locking when you want
> partial access to a database. But you do not get to read a record while it is
> being written out, you wait. So I still say, it is poor design to be trying 
> to get
> or put a member that someone is editing. Code a smart script and try again
> instead of just stacking some commands and relying on luck for it to work.
> 
> I preach what I practice. DISP=OLD exists for a reason. It may slow down
> your batch cycle, but then I do not want to lose money from my account
> because someone did not understand the importance of an enqueue.
> 
> Since you won't get the RFC for FTP changed to check ISPF internal
> enqueues, maybe you can get ISPF to not take the exclusive lock until it
> really is writing. Who cares if two people both get the member in edit as long
> as ftp can get it at anytime. And whoever is slower, wins.
> 
Red herring, again.  It's the responsibility of the implementor of an FTP
server or client for a particular system to do what that system requires to
insure integrity.  RFC 959 is properly silent on the method.  The ENQ that
failed on an FTP GET was on SPFEDIT, as I reported, not on SYSDSN.  So,
apparently FTP server is aware of and observes ISPF's integrity conventions.

> Your testing shows that another user can not get the same member you can
> get. How is that different than ftp can not get the same member you can get.
> It is not. Since you have the exclusive lock you can get it as many times as
> you can nest view, browse or start more sessions. You have it, you have it.
> 
> ISPF does not do an update-in-place to a PDS. It requests the next available
> TTR, does its writes, and updates the directory. Until the directory is 
> updated
> with the new TTR your subsequent views and browses get the still-current
> TTR and you get the data at that TTR. And until the next available TTR is
> updated to point just past the last member, a batch job with DISP=SHR that
> writes a new member will get the same TTR ISPF is using to save your member.
> 
This protocol guarantees that no reader will observe a PDS member during
updating; no ENQ is necessary to assure a valid read.  FTP server is being
unnecessarily restrictive by enforcing an SPFEDIT ENQ during a GET.

> If you really need to ignore data integrity, use UNIX. There you can have
> multiple writers and readers using files as long as they do not all follow the
> UNIX locking mechanisms. As long as any one process ignores the locking,
> they can read or write a file some other process has locked. This falls under
> better the bet

Re: Finally get to go from os390 2.10 to zOS 1.8

[Ted MacNEIL]

>It is hard to imagine that the day you cut over you are really implementing 
>new or modified applications using all the new bells and whistles of a system 
>you were not running anyway.

The problem is not bells and whistles!
It's the changing of control blocks and structures on disk.
The old system will not understand the new system.

-
Too busy driving to stop for gas!  

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

Re: Finally get to go from os390 2.10 to zOS 1.8

[Kenneth E Tomiak]

I would think the 'support' comes down to legal posturing. IBM supports n+2 
these days. That means as long as you stay within that window, they work to 
make sure the three releases play nice together. Go outside that window and 
they can not be sucked into the lawsuit against you when you you break the 
system, horribly. After that, you get to choose how much risk you are willing 
to take. Until you try to run your 'unsupported' configuration and find out if 
it 
works or not, there is uncertainty. If you are not doing a push-pull of your 
processor, and that is a big risk, do some testing. In all the migration 
material 
I read, there are frequent references to 'once you start using a new feature, 
the old system cannot handle it.'  It is hard to imagine that the day you cut 
over you are really implementing new or modified applications using all the new 
bells and whistles of a system you were not running anyway. Your old stuff 
still runs the same old way. So as Brian points out, if you do not do that, you 
can share more than you think. As long as you accept the risk.

Making the leap from 31 bit to 64 bit is not as big a challenge today as it was 
years ago. If you need to do it, all the vendor products out there are ready 
for you. Unless you have some obscure vendor who had their head in a hole. 
Get all the current products and do it. Or bring in someone who has done it.


On Fri, 4 May 2007 23:40:28 -0500, Brian Westerman 
<[EMAIL PROTECTED]> wrote:

>ah, again with the FUD.
>
>There is no issue with sharing catalogs, or RACF between OS/390 and z/OS at
>any level, you just can't do stupid things.  There are some
>incompatibilities with some products, but mostly it's a matter of two
>inconsistent versions of products that you can handle up front before the
>actual conversion.  I never said it was a nit, but it's not impossible nor
>is it particularly difficult, you just have to know what you're doing.  I've
>done it too many times at too many sites and I have not run into any
>insurmountable issues with being outside of the N-3 "rules".  It's not like
>IBM is going to say, "Wow!, you're trying to convert from OS/390 2.10 to
>Z/OS 1.8, we don't support that!, You'll just have to go away.", because
>they do provide support, they have been from time to time very helpful.  I
>will admit that I have not had to call them very much lately due to issues
>because I've already run into most, if not all, of them and have the
>solutions.
>
>I even had two conversion client contacts in 2006 passed on to me from IBM
>support, and those conversions went fine with no hitches.
>
>Doing the conversion in multiple steps is just make-work that the client
>should not have to pay for and that I don't want to have to go through
>either.  I guess if I was  really bored, I might have a different
>perspective, but there are too many other interesting things to do without
>making extra work for myself or the client.
>
>Brian
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: ftp of exclusively used Member

[Kenneth E Tomiak]

ISPF is smart enough to know what ISPF is doing so you can get away with 
browsing and viewing the contents of an ISPF member being edited. Right up 
until they perform a save. If you were able to try to view the member while 
the pds was being updated you would have a problem. Obviously, you would 
not be able to swap your screen and try to view the same member while you 
were also doing a save. But another task not following the rules could. The 
rules are there for data integrity. 

The problem with a PDS, not PDSE, comes when an ISPF task and a non-ISPF 
task try to update the same PDS. PDS, not just member. I did some work for a 
financial firm that every few months complained their batch job was not 
working. Turned out they were using DISP=SHR to put a member in a PDS their 
developers were regularly using. Every now and then, in that tiny window of 
opportunity, the batch job would try to update the pds and the same moment 
a develoepr was trying to save their work. During the process to create the 
member they both get the same TTR and start writing their data. Whoever is 
slower is the winner because they wrote last.

The RFC for FTP does not include trying to work with the ISPF enqueues. 
Therefore, exclusive use to a non-ISPF task means it is busy, try again later.

Funny you disagree, look at any operating system and any database and you 
find some form of a locking mechanism has been built to prevent access whlie 
it is being updated. And yes, they have record level locking when you want 
partial access to a database. But you do not get to read a record while it is 
being written out, you wait. So I still say, it is poor design to be trying to 
get 
or put a member that someone is editing. Code a smart script and try again 
instead of just stacking some commands and relying on luck for it to work.

I preach what I practice. DISP=OLD exists for a reason. It may slow down 
your batch cycle, but then I do not want to lose money from my account 
because someone did not understand the importance of an enqueue.

Since you won't get the RFC for FTP changed to check ISPF internal 
enqueues, maybe you can get ISPF to not take the exclusive lock until it 
really is writing. Who cares if two people both get the member in edit as long 
as ftp can get it at anytime. And whoever is slower, wins.

Your testing shows that another user can not get the same member you can 
get. How is that different than ftp can not get the same member you can get. 
It is not. Since you have the exclusive lock you can get it as many times as 
you can nest view, browse or start more sessions. You have it, you have it.

ISPF does not do an update-in-place to a PDS. It requests the next available 
TTR, does its writes, and updates the directory. Until the directory is updated 
with the new TTR your subsequent views and browses get the still-current 
TTR and you get the data at that TTR. And until the next available TTR is 
updated to point just past the last member, a batch job with DISP=SHR that 
writes a new member will get the same TTR ISPF is using to save your member.

If you really need to ignore data integrity, use UNIX. There you can have 
multiple writers and readers using files as long as they do not all follow the 
UNIX locking mechanisms. As long as any one process ignores the locking, 
they can read or write a file some other process has locked. This falls under 
better the better design principle, if you truly do not care what data you get, 
then put your data under z/OS UNIX, either an HFS or zFS based filesystem 
and do not use applications with locking.


But please, do not ask z/OS to circumvent data integrity.



On Sat, 5 May 2007 10:19:32 -0600, Paul Gilmartin 
<[EMAIL PROTECTED]> wrote:

>In a recent note, Kenneth E Tomiak said:
>
>> Date: Sat, 5 May 2007 08:57:16 -0500
>>
>> The scarier part is someone suggested how to update an exclusively held
>> member. The answer is, if you want to introduce data integrity problems to
>> your system, please do not ask us for help. There is no good reason to try 
to
>> get or put a member that is in use. z/OS 1.8 Communication Server comes
>> with a REXX API to FTP. If you are using a dumb, or blind, script to 
transfer a
>> file then you should upgrade and write some intelligent code to attempt the
>> transfer, when you get the error that it is held, let logic dictate how long 
your
>> code waits before trying again or giving up. A better design would have you
>> figuring out who is editing a member you need to transfer. Something is 
wrong
>> with your design.
>>
>I disagree.
. snip 
>-- gil
>--
>StorageTek
>INFORMATION made POWERFUL

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