Re: Dynamic change of link address

[Roy Hewitt]

Bruce,

This should be no problem, as you are not effecting all of the paths to the devices. The devices 
would only need to be offline if all the paths were changing.


To make a change like this all that you need to do is ensure that, at a minimum, all the effected 
paths are offline to the relevant devices.. so a V PATH(6000-6FFF,33),OFFLINE, and same for 53 .. 
would suffice. But a CF CHP is usually easier. Sometimes you need to do the V PATH if the CHP is 
shared with other devices and you can't take it offline. You will need to put the Paths/CHP back 
online again after the activate


Cheers

Roy

Bruce Schaefer wrote:

We have many CNTLUNIT macros defined with 8 paths, similar to:
  CNTLUNIT CUNUMBR=6F00,PATH=((CSS(0),33,73,2E,3A,53,83,5A,3E)),*
UNITADD=((00,256)), *
LINK=((CSS(0),7120,7220,7320,7420,7124,7224,7324,7424)),*
CUADD=0,UNIT=2107
  IODEVICE ADDRESS=(6000,064),CUNUMBR=
(6F00),STADET=Y,UNIT=3390B
  IODEVICE ADDRESS=(6040,192),CUNUMBR=
(6F00),STADET=Y,UNIT=3390A

The above is repeated for CUADD=1 to F to define the entire 6000-6FFF 
device range.


If we change the 71xx link addresses to 77xx (and CF CHP(33,53)
OFFLINE on all LPARs on this machine), will the ACTIVATE IODF= 
command succeed?


My recollection tells me that the command will try to DELETE the CU, 
thus all devices would need to be offline. Is this correct or will the 
activate delete the affected paths, then readd with updated link 
addresses?


Thanks,
Bruce

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



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

very strange ISHELL behaviour

[Jim McAlpine]

I've just installed z/OS 1.11 and I'm getting some strange behaviour with
ISHELL and it just occurs with user IBMUSER (which is defined with UID of
0).
What happens is that when I list a directory then enter an "e" to the left
of a file to edit it, nothing happens ie the cursor remains to the left of
the filename and the file is not opened.  I can enter "s" or "/" to the left
of the file and it will open in browse mode but edit.  I can edit files in
ISHELL with other userids no problem.  Also I can edit files with OEDIT with
IBMUSER.

Any ideas ?

Jim McAlpine

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

How to validate the existence of a file on a Server via JCL

[Hilario Garcia]

I would like to know how to test the existence of a file on a Server Directory 
(Windows or Linux) and if exist to execute a job step in an z/os jcl.

Thanks in advance.

Hilario

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

Antwort: very strange ISHELL behaviour

[Michael Klaeschen]

Jim,

have you checked REGION size in RACF TSO segment for IBMUSER? The HFS file 
to be edited must fit completely into IBMUSER's TSO ASID.

Cheers 
Michael





Jim McAlpine  
Gesendet von: IBM Mainframe Discussion List 
21.05.2010 10:30
Bitte antworten an
IBM Mainframe Discussion List 


An
IBM-MAIN@bama.ua.edu
Kopie

Thema
very strange ISHELL behaviour






I've just installed z/OS 1.11 and I'm getting some strange behaviour with
ISHELL and it just occurs with user IBMUSER (which is defined with UID of
0).
What happens is that when I list a directory then enter an "e" to the left
of a file to edit it, nothing happens ie the cursor remains to the left of
the filename and the file is not opened.  I can enter "s" or "/" to the 
left
of the file and it will open in browse mode but edit.  I can edit files in
ISHELL with other userids no problem.  Also I can edit files with OEDIT 
with
IBMUSER.

Any ideas ?

Jim McAlpine

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

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

Re: FTP Get Blocked by ISPF EDIT

[Shmuel Metz (Seymour J.)]

In , on 05/20/2010
   at 12:28 PM, Paul Gilmartin  said:

>And, truly annoying:

>/bin/cp /what/ever "//'SYS2.MVSMODS.CNTL(ISTINCLM)'"

>requests EXCL SYSDSN ENQ.  I think this misspecification is inherent
>in the C RTL.

It's not a misspecification. Would you really prefer an ABEND or a
damaged directory?

The original design error was in not specifying safe PDS sharing back
in the early OS/360 days, but I can't see any clean way forward at
this late date.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: FTP Get Blocked by ISPF EDIT

[Shmuel Metz (Seymour J.)]

In , on 05/20/2010
   at 06:17 PM, Paul Gilmartin  said:

>TRANSMIT is a horse of a different choler. 

Perhaps, but it doesn't appear to be ignoring DCB attributes.

>TRANSMIT FOO.BAR FILE(PUTDD) OUTDSN(TEMP.FOOXMIT)

What does the TSO command reference say about the semantics of that
command?

>... and watched as IEBCOPY messages scrolled by for the unload of
>the entire SYS1.MACLIB.  Wrong, wrong! 

Is it?

>"Using Data Sets" makes it very clear that when a data set name 
>and member are specified, the allocation is Physical Sequential.

Does it? Certainly "Retrieving a Member of a PDS" says no such thing.

>TRANSMIT ought to have simply OPENed a DCB for PUTDD and made an 
>XMIT package of whatever it found on a QSAM read.

XMIT ought to have done whatever the manual specified that it do. What
does IEBCOPY do with

 IN DD DSN=foo(bar)
 ...
 C I=IN,O=OUT

?

For that matter, try writing a program that specifies DSORG=PO and see
what effect an explicit member name has on it.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: FTP Get Blocked by ISPF EDIT

[Binyamin Dissen]

On Thu, 20 May 2010 18:17:18 -0500 Paul Gilmartin 
wrote:

:>BTW, how can I interrupt IEBCOPY in this situation.  PA1
:>gave me a READY prompt, but when I pressed ENTER the IEBCOPY
:>messages resumed.  I finally resigned myself to pressing
:>ENTER until they finished scrolling by.)

Pressing enter after PA1 means ignore the PA1 (for the native TSO handling).

Type anything other than ? to terminate the previous command.

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: very strange ISHELL behaviour

[Jim McAlpine]

On Fri, May 21, 2010 at 10:06 AM, Michael Klaeschen <
michael.klaesc...@deutscherring.de> wrote:

> Jim,
>
> have you checked REGION size in RACF TSO segment for IBMUSER? The HFS file
> to be edited must fit completely into IBMUSER's TSO ASID.
>
> Cheers
> Michael
>
> Michael, the region size is the same as the users who can edit the same
file.

Jim McAlpine

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

Is there z/VSE APF authorzsation equivalent?

[Steve Austin]

Is there a z/VSE APF authorization equivalent?
The VSE MODESET macro description says the program must be identified as
'job control', which is not a great string to search for.
 
Thanks
 
Steve

- 
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: very strange ISHELL behaviour

[Lizette Koehler]

Jim,

I thought that the Size in the TSO SEGMENT was only what the user would get
if the user did not specify it at logon time.

Is it possible that they have a smaller size on the LOGON panel rather than
using the TSO SEGMENT SIZE?

Lizette


> 
> > Jim,
> >
> > have you checked REGION size in RACF TSO segment for IBMUSER? The HFS
> file
> > to be edited must fit completely into IBMUSER's TSO ASID.
> >
> > Cheers
> > Michael
> >
> > Michael, the region size is the same as the users who can edit the
> same
> file.
> 
> Jim McAlpine

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

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[Shmuel Metz (Seymour J.)]

In , on
05/20/2010
   at 09:35 AM, zMan  said:

>What's to explain? TSO is old and grotty, and supporting random
>screen sizes in fullscreen apps is a pain.

I've never had any trouble with nonstandard screen sizes in TSO.
Perhaps you're confusing ISPF with TSO.

BTW, I would expect nonstandard console screen sizes to be a problem.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Getting "BIND/LINK" date out of load module members

[Shmuel Metz (Seymour J.)]

In <4bf49653.6f0f.008...@efirstbank.com>, on 05/20/2010
   at 01:53 AM, Frank Swarbrick  said:

>I find it perplexing, though, that there is apparently no field in a
>load module PDS that indicates when a member was created and/or last
>updated. 

What are IDRDATA, chopped liver?

>Why is it there for non-load module PDSs

It isn't. Not all members are created by ISPF.

>but not for load module PDSs?

It's been in load modules for around 4 decades. In fact, I believe
that IDRDATA is older than SPF. Anyone have the exact dates?

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

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

Re: LINK Question (SRB Mode?)

[Shmuel Metz (Seymour J.)]

In <201005201915.o4kjfwmd004...@bama.ua.edu>, on 05/20/2010
   at 03:15 PM, Art Celestini  said:

>Content-Type: text/plain; charset="us-ascii"

Please stick to ASCII when you emit that header field. The code points
'93'X and '94'X render randomly[1] without a declaration of character
set.

>A colleague has written me about a set of circumstances he is
>observing:   Program “A” is authorized, running in Key 7, TCB mode,
>and issues a LINK for  Program “B”.  When Program “B” gets control,
>it finds PSATOLD=0 and  PSASRBM=04. 

I believe that you are misinterpreting those fields. Make a local copy
*before* you take the dump and see what you get.

>How could LINK possibly give the target program control in SRB Mode?

It couldn't, legitimately, and an undetected bug of that magnitude is
unlikely.

[1] E.g., as “ and ”. I should have charset=iso-8859-15 in my
header and those characters should render as o^ and o umlaut
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Of interest to the Independent Contractors on the list

[Shmuel Metz (Seymour J.)]

In <20100520042808.ad5f81c...@mail.ase.com.au>, on 05/19/2010
   at 09:13 PM, Graeme Gibson  said:

>Countless other professionals did corresponding good work and as a 
>direct consequence "Y2K" was not a disaster at all. 

Indeed. On the flip side, not every Y2K bug was worth fixing. At NSF
we had a monitor that showed the date as 19100; the only real effect
that bug had was to provoke the occasional chuckle.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[Shmuel Metz (Seymour J.)]

In , on 05/20/2010
   at 03:48 AM, Nick Jones  said:

>Sorry to pick up on this old post but we have just upgraded from z/OS
>1.9 to  z/OS 1.11 and, like you, take advantage of screen sizes in
>excess of 62x160.

There are two distinct issues:

 1. Screen geometry
 2. Address size.

The 3290 works with 14-bit addressing (0-16,383) of a 9920 byte
buffer. Get much larger and you'll need to use 16-bit addressing; I
don't know whether z/OS supports that for TSO, ISPF or DIDOCS.

In the simplest case you'll need a BIND image that specifies your
primary and secondary screen size, either explicitly or by specifying
the result of WSF RP-Query. I don't know whether ISPF supports
explicit partitions for anything larger than a 3290.

For ISPF I'd advise using DATA rather than MAX.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Getting "BIND/LINK" date out of load module members

[Shmuel Metz (Seymour J.)]

In <9118ef7037e140479786802e36812d7504b45...@syssrv35.ad.ilstu.edu>,
on 05/19/2010
   at 02:45 PM, "Davis, Kriss"  said:

>I am working on process to monitor/audit load libraries for
>new/replaced members during a date range.  I have a working version
>that uses AMBLIST with a SYSIN of LISTIDR.

I hope that they've improved the code since the last time that I had
to deal with it.

The CBT is full of programs for extracting IDR data. I wouldn't be
surprised if every single one of them was faster than AMBLIST. Or take
Roland's suggestion and use IEWBIND.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: very strange ISHELL behaviour

[Jim McAlpine]

On Fri, May 21, 2010 at 12:18 PM, Lizette Koehler
wrote:

> Jim,
>
> I thought that the Size in the TSO SEGMENT was only what the user would get
> if the user did not specify it at logon time.
>
> Is it possible that they have a smaller size on the LOGON panel rather than
> using the TSO SEGMENT SIZE?
>
> Lizette
>
>
>
Lizette, both userids have the same settings.  Anyhow I would think that I
would get some sort of abend or message at least if it was a size problem.
I'm seeing absolutely nothing.

Jim McAlpine

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

Re: Of interest to the Independent Contractors on the list

[Binyamin Dissen]

On Fri, 21 May 2010 06:43:42 -0400 "Shmuel Metz (Seymour J.)"
 wrote:

:>In <20100520042808.ad5f81c...@mail.ase.com.au>, on 05/19/2010
:>   at 09:13 PM, Graeme Gibson  said:

:>>Countless other professionals did corresponding good work and as a 
:>>direct consequence "Y2K" was not a disaster at all. 

:>Indeed. On the flip side, not every Y2K bug was worth fixing. At NSF
:>we had a monitor that showed the date as 19100; the only real effect
:>that bug had was to provoke the occasional chuckle.
 
So it was smart enough to know that it needed 3 digits for the end part of the
year, but then it concatenated the string '19' in front?

One wonders who programmed such a thing (unless it was PL/I which would do
that automatically).

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Antwort: Re: very strange ISHELL behaviour

[Michael Klaeschen]

Jim,

you do not see any messages on the screen, ok. And I agree, you should see 
some messages indicating what's missing. Did you look in the JES-spool for 
the TSO procedure? I mean check SDSF, e.g. JESMSGLG DD.

Cheers
Michael




Jim McAlpine  
Gesendet von: IBM Mainframe Discussion List 
21.05.2010 13:40
Bitte antworten an
IBM Mainframe Discussion List 


An
IBM-MAIN@bama.ua.edu
Kopie

Thema
Re: very strange ISHELL behaviour






On Fri, May 21, 2010 at 12:18 PM, Lizette Koehler
wrote:

> Jim,
>
> I thought that the Size in the TSO SEGMENT was only what the user would 
get
> if the user did not specify it at logon time.
>
> Is it possible that they have a smaller size on the LOGON panel rather 
than
> using the TSO SEGMENT SIZE?
>
> Lizette
>
>
>
Lizette, both userids have the same settings.  Anyhow I would think that I
would get some sort of abend or message at least if it was a size problem.
I'm seeing absolutely nothing.

Jim McAlpine

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

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

Re: How to validate the existence of a file on a Server via JCL

[Roberto Halais]

Using a Rexx script
1-From z/os to the server establish an FTP connection to the folder where
the file should be..
2-Do a directory list
3-Catch the output in Rexx
4-Parse the output and look for your file.
5- If found execute your job step.

At least that's how I would do it.
Regards,
Roberto


On 5/21/10, Hilario Garcia  wrote:
>
> I would like to know how to test the existence of a file on a Server
> Directory
> (Windows or Linux) and if exist to execute a job step in an z/os jcl.
>
> Thanks in advance.
>
> Hilario
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
"It is no measure of health to be well adjusted to a profoundly sick
society." -Krishnamurti

"I am as you, in you, for you. One as you in all, as all, forever. My call
is your call."

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

Re: very strange ISHELL behaviour

[Hunkeler Peter (KIUP 4)]

I don't have access to a uid=0 userid, so I cannot
test myself. Anayway, 

... what are the differences in the OMVS segments of
both users?

... can the uid=0 userid edit plain standard MVS datasets?

... any messages in any of the logs (JESYSMSG, ISPLOG, SYSLOG)

--
Peter Hunkeler
CREDIT SUISSE AG

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

Re: Is there z/VSE APF authorzsation equivalent?

[Chuck Arney]

Use the PRODID DEFINE followed by PRODID AUTH=YES macros to define
yourself as an authorized task before using MODESET.

Chuck Arney
illustro Systems International, LLC
http://www.illustro.com
Internet-enable your applications with z/Ware V2
Voice: 214-800-8900 X#5562
--
This e-mail is private and may be confidential and is for the intended
recipient only. If misdirected, please notify us by telephone and
confirm that it has been deleted from your system and any copies
destroyed. If you are not the intended recipient you are strictly
prohibited from using, printing, copying, distributing or disseminating
this e-mail or any information contained in it.  
  
We use reasonable measures to virus scan all E-mails leaving illustro
but no warranty is given that this E-mail and any attachments are virus
free. You should ensure you have adequate measures in place for your own
virus checking.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Steve Austin
Sent: Friday, May 21, 2010 5:34 AM
To: IBM-MAIN@bama.ua.edu
Subject: Is there z/VSE APF authorzsation equivalent?

Is there a z/VSE APF authorization equivalent?
The VSE MODESET macro description says the program must be identified as
'job control', which is not a great string to search for.
 

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

Re: FTP Get Blocked by ISPF EDIT

[Paul Gilmartin]

On Fri, 21 May 2010 08:25:27 +0200, Hunkeler Peter (KIUP 4) wrote:

>>o Kudos to FTP server -- the messages are excellent.
>
>Could only be topped if the message would the who the
>holder was.
>
It does.  Re-quoting from the OP:

> is held by: 008F EDJXADM  EXCL on SPFEDIT

-- gil

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

Re: FTP Get Blocked by ISPF EDIT

[Paul Gilmartin]

On Fri, 21 May 2010 08:25:58 +0200, Hunkeler Peter (KIUP 4) wrote:

>>Would anyone care to submit a Requirement that ISPF defer
>>requesting the EXCL SPFEDIT until the first SAVE?
>
>I would vote against it. Definitely! If I'm in EDIT, I expect
>that nothing can change the content under the covers, no matter
>whether I'm going to actuially change the content or not.
>
My question was rhetoric.  In my next paragraph I pointed out
hazards.  I vote with you.

>Ed: How happy would you be if your automated ftp process
>successfully replaces the member someone else is editing at
>the same time. A single SAVE and your successfull ftp isn't
>worth a dime anymore.
>
Ed's example concerned retrieving the member, not storing it.
But I pointed out the hazard that during an Edit session the
member may be in an invalid state.

-- gil

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

Re: How to validate the existence of a file on a Server via JCL

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hilario Garcia
> Sent: Friday, May 21, 2010 3:41 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: How to validate the existence of a file on a Server via JCL
> 
> I would like to know how to test the existence of a file on a 
> Server Directory 
> (Windows or Linux) and if exist to execute a job step in an z/os jcl.
> 
> Thanks in advance.
> 
> Hilario

How are you accessing the Windows/Linux server? Is the Windows/Linux 
file/directory directly readable on z/OS using SMB or NFS? Or do you need to 
use something like ftp?

For FTP, run a step like:

//FTP03EXEC  PGM=FTP,REGION=6M,PARM='(EXIT'
//SYSPRINT DD  SYSOUT=*
//OUTPUT   DD  SYSOUT=*,DCB=BLKSIZE=133
//INPUTDD  *
server.name
user
password
ls file-name-to-test
/*
//EXISTS EXEC PGM=DOIT,COND=(0,NE,FTP03)
//... MORE JCL
//*

Now, if you're using SMB or NFS to directly read the server's data as it if 
were a local UNIX file, then it would be similar, but different.

//TESTIT EXEC PGM=BPXBATCH,
// PARM='ls file-to-test'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDIN DD PATH='/dev/null',PATHOPTS=(ORDONLY)
//*
//EXISTS EXEC PGM=DOIT,COND=(0,NE,TESTIT)
//... MORE JCL
//*


--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

Re: FTP Get Blocked by ISPF EDIT

[Paul Gilmartin]

On Fri, 21 May 2010 04:56:35 -0400, Shmuel Metz (Seymour J.) wrote:
>
>>/bin/cp /what/ever "//'SYS2.MVSMODS.CNTL(ISTINCLM)'"
>
>>requests EXCL SYSDSN ENQ.  I think this misspecification is inherent
>>in the C RTL.
>
>It's not a misspecification. Would you really prefer an ABEND or a
>damaged directory?
>
>The original design error was in not specifying safe PDS sharing back
>in the early OS/360 days, but I can't see any clean way forward at
>this late date.
>
The clean way forward was devised by [I]SPF some time ago in the
SPFEDIT ENQ.  This is effective.  I believe it assures data integrity;
no ABEND; no damaged directory.  NFS server and FTP server (others?)
use the technique to cooperate with ISPF.  C RTL ought to do likewise.

-- gil

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

Re: very strange ISHELL behaviour

[Joel C. Ewing]

Just as a clarification, the size in the RACF TSO Segment is where the
initial default OR last used value for TSO logon size is retained.  If
the user changes the value on his TSO logon panel, the most recent Size
value he specified for a successful logon will then be in his TSO
Segment.  It is only the MaxSize limit for the Size that the user can
specify at logon that is fixed in his TSO segment, changeable only by
RACF Admin.

Similar changes at TSO logon occur in TSO Segment if the user changes
his logon Account Number or Logon Proc, but in those cases restrictions
on what values may be used are enforced based on whether the user has
READ access to the  appropriate RACF profiles protecting those resources.

So looking at RACF TSO Segment values shows how the user last logged on.
  JC Ewing

On 05/21/2010 06:20 AM, Lizette Koehler wrote:
> Jim,
> 
> I thought that the Size in the TSO SEGMENT was only what the user would get
> if the user did not specify it at logon time.
> 
> Is it possible that they have a smaller size on the LOGON panel rather than
> using the TSO SEGMENT SIZE?
> 
> Lizette
> 
> 
...

-- 
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org

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

z/OS file system and some Friday thoughts

[Thomas Berg]

As I have followed some threads lately and also many
times earlier about the file system in general and PDS(E)s
in particular I got an (maybe OT) idea.  (Beware! :) )

The goal is to be able to have any string in general as
a "data set name"/file name and in particular *nix type
name/structure.  And that in z/OS native.

As we have 44 bytes available in the catalog(s), I think we can
do something like this:

- Use 16 bytes for a hash (MDM5/SHA-2) of the file name.
- Use 16 bytes for a hash of the "dir path".
- Alternatively using 16 bytes hash for the whole string of
path and file name.  But I think that separate hashes would
get some performance benefits when handling "directorys".
- We must probably use an (initial?) byte with e g nulls for avoiding
collision with the old data set names.
- As an additional option we could use maybe 4 bytes for file
version/generation handling.

E g we have a file "Just a test etc." which have the hash
x'F296A5AE68F284954EBF47EC5EEFD72E', in the "dir"
"/First level dir/Second level dir/" which have the hash
x'847FD35FD88274EC0EDA528E7CD7A65A'.

So the 44 (?) bytes would maybe look like:
x'00F296A5AE68F284954EBF47EC5EEFD72E847FD35FD88274EC0EDA528E7CD7A65A00'.

Enq:s would then also have the hash as keys etc.


Am I an idiot or just a typical programmer ?  :)



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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Of interest to the Independent Contractors on the list

[Elardus Engelbrecht]

Binyamin Dissen wrote:
>:>Indeed. On the flip side, not every Y2K bug was worth fixing. At NSF
>:>we had a monitor that showed the date as 19100; the only real effect
>:>that bug had was to provoke the occasional chuckle.
>
>So it was smart enough to know that it needed 3 digits for the end part of 
the
>year, but then it concatenated the string '19' in front?

Perhaps, but AFAIK, such systems stored the year in two fields. One field was 
used for century and another field for 2 digit year.

In this case I suspect, it was stored as x'13' for 19 in one field for century 
and 
another field x'64' for year. In such systems, the year 2000 should be 
stored/adjusted as x'14' and x'00'. Or perhaps fixed to have one field for year.

Then you get that formatting errors too resulting in 5 bytes of display 
values...

Are those monitors fixed at this time? ;-D

Groete / Greetings
Elardus Engelbrecht

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

Re: Getting "BIND/LINK" date out of load module members

[Greg Price]

Frank Swarbrick wrote:
 On 5/20/2010 at 2:22 AM, in message
> <29s9v5lniuvtpalf97r7chtu7ogfmj7...@4ax.com>, Binyamin Dissen
>   wrote:
snippage
>>
>> Submit a requirement.
> 
> No doubt.  I'm just amazed that such a requirement wasn't submited 30 years 
> ago.
> 
> Frank


30 years ago IBM would have said (and IIRC did say) that those sort of
timestamps are kept for the file, as other OSes keep such things for their
files.  (Granted, MVS keeps a reference data instead of a modification date.)

Further, PDS members are not files, but parts of a file (physical files being
called "data sets" in MVS parlance).  If you want those sorts of timestamps
kept in the file's data content, then make your application write such data
when loading data into such a file.

As has been stated, the linkage editor <-> program binder, and ISPF are
two such applications which which write timestamps within the content
of data written to their output files.

Cheers,
Greg

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

Re: zOS Network Authentication Service (Kerberos)

[van der Grijn, Bart (B)]

Mark, I might be showing my AD ignorance here, but I thought that you
still had domain controllers when using AD. We are heavy SMB users and
are AD. I played with the pass through authentication a couple of years
ago and it seemed to work ok. We abandoned it and went to DCE segments
due to reliability issues, but it might match your needs. 

Bart 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Mark Jacobs
Sent: Wednesday, May 19, 2010 12:29 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: zOS Network Authentication Service (Kerberos)

On 05/19/10 11:13, Walt Farrell wrote:
> On Wed, 19 May 2010 10:12:01 -0400, Mark
Jacobs
> wrote:
>
>
>> Is anyone using the zOS Network Authentication Service to generate
>> passtickets for authentication (instead of passwords) to RACF? If so
I'd
>> like to hear about your experiences.
>>
>>  
> I don't think I understand that question, Mark.  How is NAS (Kerberos)
> related to PassTickets at all?  They're totally different
technologies.
> What do you need to accomplish, and in what user/application contexts?
>
>

My end desire is for a process running on a Windows based workstation 
access a SMB share under zOS. As far as I know SMB authenticates one of 
three ways;

   1. Windows/NT Domain controller - Not an option since it's out of our
  environment, replaced by Active Directory.
   2. Racf authentication - There is strong resistance against using a
  hardcoded userid/password coded in this application so my very
  early research led me to passtickets.
   3. None(Guest Access) - Not acceptable.

What I'm looking for is for the process on the workstation (already 
authenticated by AD) to be accepted by RACF as an authenticated zOS 
userid without supplying a password.

-- 
Mark Jacobs
Time Customer Service
Tampa, FL


It is impossible to make anything foolproof, because fools
are so ingenious.

  -- Robert Heinlein

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

Re: z/OS file system and some Friday thoughts

[Elardus Engelbrecht]

Thomas Berg wrote:

[ ... lots of interesting things about hashes ... ] 

Curiousity question: Where are you going to store those hashes?

>Am I an idiot or just a typical programmer ?  :)

You are NOT licensed to be an idiot. ;-D

Actually what you suggested could be very useful. Perhaps a SHARE 
submission?

Groete / Greetings
Elardus Engelbrecht

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

Re: z/OS file system and some Friday thoughts

[Joel C. Ewing]

On 05/21/2010 08:03 AM, Thomas Berg wrote:
> As I have followed some threads lately and also many
> times earlier about the file system in general and PDS(E)s
> in particular I got an (maybe OT) idea.  (Beware! :) )
> 
> The goal is to be able to have any string in general as
> a "data set name"/file name and in particular *nix type
> name/structure.  And that in z/OS native.
> 
> As we have 44 bytes available in the catalog(s), I think we can
> do something like this:
> 
> - Use 16 bytes for a hash (MDM5/SHA-2) of the file name.
> - Use 16 bytes for a hash of the "dir path".
> - Alternatively using 16 bytes hash for the whole string of
> path and file name.  But I think that separate hashes would
> get some performance benefits when handling "directorys".
> - We must probably use an (initial?) byte with e g nulls for avoiding
> collision with the old data set names.
> - As an additional option we could use maybe 4 bytes for file
> version/generation handling.
> 
> E g we have a file "Just a test etc." which have the hash
> x'F296A5AE68F284954EBF47EC5EEFD72E', in the "dir"
> "/First level dir/Second level dir/" which have the hash
> x'847FD35FD88274EC0EDA528E7CD7A65A'.
> 
> So the 44 (?) bytes would maybe look like:
> x'00F296A5AE68F284954EBF47EC5EEFD72E847FD35FD88274EC0EDA528E7CD7A65A00'.
> 
> Enq:s would then also have the hash as keys etc.
> 
> 
> Am I an idiot or just a typical programmer ?  :)
> Regards,
> Thomas Berg
> _
> Thomas Berg   Specialist   A M   SWEDBANK
...

The obvious problem with this of course is that hash functions by their
very nature (mapping a larger domain to a smaller range) cannot be
one-to-one.  They work reliably for such things as symbol table lookup
only because you also have the full string available, both as the search
argument and in the table in order to resolve collisions when two
strings hash to the same value.  A hash value unaccompanied by the full
string does not represent a unique string and is thus ambiguous.

Most programmers/users would not find it acceptable to request a
read/update/enqueue on "file a" and have it give the same results as a
reference to some unknown and unrelated "file x", just because they
happened to hash to the same value.

If the hash function mapped to an equal or larger range, then it would
be possible to have uniqueness; but then the hash value would require
more bits to represent it than the original string of symbols and
nothing would be gained by the substitution.

-- 
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org

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

Re: very strange ISHELL behaviour

[Jim McAlpine]

On Fri, May 21, 2010 at 1:15 PM, Michael Klaeschen <
michael.klaesc...@deutscherring.de> wrote:

> Jim,
>
> you do not see any messages on the screen, ok. And I agree, you should see
> some messages indicating what's missing. Did you look in the JES-spool for
> the TSO procedure? I mean check SDSF, e.g. JESMSGLG DD.
>
> Cheers
> Michael
>
>
>
There are no messages anywhere.  Not on the screen or in the IBMUSER log or
in the MVS log.

Ziltch.

Jim McAlpine

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

Re: FTP Get Blocked by ISPF EDIT

[Hunkeler Peter (KIUP 4)]

>Ed's example concerned retrieving the member, not storing it.

It seems this is not my best day for posting. I'll go look
for a new pair of glasses; These seem to blank out words :-)

--
Peter Hunkeler
Credit Suisse

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

Re: very strange ISHELL behaviour

[Jim McAlpine]

On Fri, May 21, 2010 at 1:33 PM, Hunkeler Peter (KIUP 4) <
peter.hunke...@credit-suisse.com> wrote:

> I don't have access to a uid=0 userid, so I cannot
> test myself. Anayway, 
>
> ... what are the differences in the OMVS segments of
>both users?
>
> ... can the uid=0 userid edit plain standard MVS datasets?
>
> ... any messages in any of the logs (JESYSMSG, ISPLOG, SYSLOG)
>
> --
> Peter Hunkeler
> CREDIT SUISSE AG
>
>
>

uid for IBMUSER is -

OMVS INFORMATION

UID= 00
HOME= /
PROGRAM= /bin/sh
CPUTIMEMAX= NONE
ASSIZEMAX= NONE
FILEPROCMAX= NONE
PROCUSERMAX= NONE
THREADSMAX= NONE
MMAPAREAMAX= NONE
uid for other user is -

OMVS INFORMATION

UID= 001001
HOME= /user/maint
PROGRAM= /bin/sh
CPUTIMEMAX= NONE
ASSIZEMAX= NONE
FILEPROCMAX= NONE
PROCUSERMAX= NONE
THREADSMAX= NONE
MMAPAREAMAX= NONE
and yes IBMUSER can edit normal MVS files as well as edit OMVS files using
3.17 and OEDIT.

and no there are no messages anywhere.

Jim McAlpine

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

Re: FTP Get Blocked by ISPF EDIT

[Hunkeler Peter (KIUP 4)]

>>Could only be topped if the message would the who the
>>holder was.
>>
>It does.  Re-quoting from the OP:
>
>> is held by: 008F EDJXADM  EXCL on SPFEDIT

My appologies go to FTP! 

--
Peter Hunkeler
Credit Suisse

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

SMPE assemble

[Mark Pace]

I'm trying to apply maintenance.  In a a PTF the tries to assemble a module.
 In the assembly I'm getting this warning

** ASMA429W SYSPRINT LRECL should be at least 133 when GOFF/XOBJECT option
is specified

And that causes the Apply to fail because of RC being 4.

I looked in the SMPE Utility
 LOAD MODULE NAME===> ASMA90   (Name of load module

invoked for this utility)



 HIGHEST RETURN CODE ===> 0(Value between 0 and 16)

The highest return code to

be considered successful.

Note: Value may be overridden

by LMOD Return Code subentry

 PRINT DD NAME   ===> SYSPRINT (Name of PRINT DD

statement to be used)

 PARM===> XREF(SHORT),DECK,NOOBJECT,GOFF,LIST(133),OPTABLE(U

 ===> NI)


Being still fairly new SMPE I'm not sure if the problem is that I need a RC
value of 4 not 0  Or the GOFF parameter is a problem, or I've left some DD
statement out of my Apply JCL to cover the GOFF output.  Anyone have a
suggestion on what maybe wrong?


-- 
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317

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

Re: very strange ISHELL behaviour

[J. D. Cassidy]

Jim,


I am also running a 1.11 system (ADCD) and I do NOT have the editing
problems that seem to plaguing you.

Here is a RACF display of IBMUSER:

==
USER=IBMUSER  NAME=  OWNER=IBMUSER   CREATED=95.157
 DEFAULT-GROUP=SYS1 PASSDATE=10.084 PASS-INTERVAL=N/A PHRASEDATE=N/A
 ATTRIBUTES=SPECIAL OPERATIONS
 REVOKE DATE=NONE   RESUME DATE=NONE
 LAST-ACCESS=10.141/15:50:18
 CLASS AUTHORIZATIONS=NONE
 NO-INSTALLATION-DATA
 NO-MODEL-NAME
 LOGON ALLOWED   (DAYS)  (TIME)
 -
 ANYDAY  ANYTIME
  GROUP=SYSCTLG   AUTH=JOIN CONNECT-OWNER=IBMUSER   CONNECT-DATE=95.157
CONNECTS=00  UACC=READ LAST-CONNECT=UNKNOWN
CONNECT ATTRIBUTES=NONE
REVOKE DATE=NONE   RESUME DATE=NONE
  GROUP=VSAMDSET  AUTH=JOIN CONNECT-OWNER=IBMUSER   CONNECT-DATE=95.157
CONNECTS=00  UACC=READ LAST-CONNECT=UNKNOWN
CONNECT ATTRIBUTES=NONE
REVOKE DATE=NONE   RESUME DATE=NONE
  GROUP=SYS1  AUTH=JOIN CONNECT-OWNER=IBMUSER   CONNECT-DATE=95.157
CONNECTS= 4,850  UACC=READ LAST-CONNECT=10.141/15:50:18
CONNECT ATTRIBUTES=NONE
REVOKE DATE=NONE   RESUME DATE=NONE
SECURITY-LEVEL=NONE SPECIFIED
CATEGORY-AUTHORIZATION
 NONE SPECIFIED
SECURITY-LABEL=NONE SPECIFIED

TSO INFORMATION
---
ACCTNUM= ACCT#
PROC= ISPFPROC
SIZE= 02048000
MAXSIZE= 02096128
UNIT= 3390
USERDATA= 
COMMAND= ispf

OMVS INFORMATION

UID= 00
HOME= /u/ibmuser
PROGRAM= /bin/sh
CPUTIMEMAX= NONE
ASSIZEMAX= NONE
FILEPROCMAX= NONE
PROCUSERMAX= NONE
THREADSMAX= NONE
MMAPAREAMAX= NONE


==


Maybe you might spot something...



Regards,



John








=> On Fri, May 21, 2010 at 1:33 PM, Hunkeler Peter (KIUP 4) <
=> peter.hunke...@credit-suisse.com> wrote:
=>
=>> I don't have access to a uid=0 userid, so I cannot
=>> test myself. Anayway, 
=>>
=>> ... what are the differences in the OMVS segments of
=>>both users?
=>>
=>> ... can the uid=0 userid edit plain standard MVS datasets?
=>>
=>> ... any messages in any of the logs (JESYSMSG, ISPLOG, SYSLOG)
=>>
=>> --
=>> Peter Hunkeler
=>> CREDIT SUISSE AG
=>>
=>>
=>>
=>
=> uid for IBMUSER is -
=>
=> OMVS INFORMATION
=> 
=> UID= 00
=> HOME= /
=> PROGRAM= /bin/sh
=> CPUTIMEMAX= NONE
=> ASSIZEMAX= NONE
=> FILEPROCMAX= NONE
=> PROCUSERMAX= NONE
=> THREADSMAX= NONE
=> MMAPAREAMAX= NONE
=> uid for other user is -
=>
=> OMVS INFORMATION
=> 
=> UID= 001001
=> HOME= /user/maint
=> PROGRAM= /bin/sh
=> CPUTIMEMAX= NONE
=> ASSIZEMAX= NONE
=> FILEPROCMAX= NONE
=> PROCUSERMAX= NONE
=> THREADSMAX= NONE
=> MMAPAREAMAX= NONE
=> and yes IBMUSER can edit normal MVS files as well as edit OMVS files using
=> 3.17 and OEDIT.
=>
=> and no there are no messages anywhere.
=>
=> Jim McAlpine
=>
=> --
=> For IBM-MAIN subscribe / signoff / archive access instructions,
=> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
=> Search the archives at http://bama.ua.edu/archives/ibm-main.html
=>


John Cassidy (Dipl.-Ingr.)

Kapellenstr. 21a

D-65193 Wiesbaden

EU



Mobile: +49 (0) 170 794 3616


http://www.JDCassidy.net

http://en.federaleurope.org/

http://sva-zhosting.com/en/index.php

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

Re: very strange ISHELL behaviour

[Lizette Koehler]

Then I would use ISPF TEST or ISPVCALL to see if one of them can capture any 
additional information.

Lizette




>
>> Jim,
>>
>> you do not see any messages on the screen, ok. And I agree, you should see
>> some messages indicating what's missing. Did you look in the JES-spool for
>> the TSO procedure? I mean check SDSF, e.g. JESMSGLG DD.
>>
>> Cheers
>> Michael
>>
>>
>>
>There are no messages anywhere.  Not on the screen or in the IBMUSER log or
>in the MVS log.
>
>Ziltch.
>
>

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

Re: very strange ISHELL behaviour

[Lizette Koehler]

It is interesting that for IBMUSER you have ROOT for home
But the other id has /user/maint

Not sure if that might be suspect or not.

Lizette



>On Fri, May 21, 2010 at 1:33 PM, Hunkeler Peter (KIUP 4) <
>peter.hunke...@credit-suisse.com> wrote:
>
>> I don't have access to a uid=0 userid, so I cannot
>> test myself. Anayway, 
>>
>> ... what are the differences in the OMVS segments of
>>both users?
>>
>> ... can the uid=0 userid edit plain standard MVS datasets?
>>
>> ... any messages in any of the logs (JESYSMSG, ISPLOG, SYSLOG)
>>
>> --
>> Peter Hunkeler
>> CREDIT SUISSE AG
>>
>>
>>
>
>uid for IBMUSER is -
>
>OMVS INFORMATION
>
>UID= 00
>HOME= /
>PROGRAM= /bin/sh
>CPUTIMEMAX= NONE
>ASSIZEMAX= NONE
>FILEPROCMAX= NONE
>PROCUSERMAX= NONE
>THREADSMAX= NONE
>MMAPAREAMAX= NONE
>uid for other user is -
>
>OMVS INFORMATION
>
>UID= 001001
>HOME= /user/maint
>PROGRAM= /bin/sh
>CPUTIMEMAX= NONE
>ASSIZEMAX= NONE
>FILEPROCMAX= NONE
>PROCUSERMAX= NONE
>THREADSMAX= NONE
>MMAPAREAMAX= NONE
>and yes IBMUSER can edit normal MVS files as well as edit OMVS files using
>3.17 and OEDIT.
>
>and no there are no messages anywhere.
>
>

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

Re: SMPE assemble

[Mary Anne Matyaz]

Mark, 
JES2 1.11 requires the parms GOFF and LIST(133). See the program directory 
or PSP bucket. (http://www-01.ibm.com/support/docview.wss?
uid=isg1_ZOSV1R11_ZOSGEN and find 'goff') 
 
I ran the following to update the options: 

//SMPCNTL  DD  * 
  SET BOUNDARY(GLOBAL) . 
  UCLIN .
  REP UTILITY(ASMA90)
   NAME(ASMA90)  
   PARM(XREF(SHORT),NOLIST,DECK,NOOBJECT,GOFF,LIST(133)).
  ENDUCL .   

Mary Anne

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

Re: SMPE assemble

[Mark Pace]

I have the correct PARM.  The problem must be with not having the correct
JCL to provide for the output of the GOFF data.

On Fri, May 21, 2010 at 10:02 AM, Mary Anne Matyaz
wrote:

> Mark,
> JES2 1.11 requires the parms GOFF and LIST(133). See the program directory
> or PSP bucket. (http://www-01.ibm.com/support/docview.wss?
> uid=isg1_ZOSV1R11_ZOSGEN and find 'goff')
>
> I ran the following to update the options:
>
> //SMPCNTL  DD  *
>  SET BOUNDARY(GLOBAL) .
>  UCLIN .
>  REP UTILITY(ASMA90)
>   NAME(ASMA90)
>   PARM(XREF(SHORT),NOLIST,DECK,NOOBJECT,GOFF,LIST(133)).
>  ENDUCL .
>
> Mary Anne
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317

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

Re: SMPE assemble

[Mary Anne Matyaz]

Mark, there's a mention of that as well in the bucket: 

ALSO, YOU NEED TO EITHER:
 SPECIFY A UNIQUE OUTPUT FILE USING THE PRINT OPERAND, (FOR
 EXAMPLE, PRINT(ASMPRINT)) AND CREATE A DDDEF IN YOUR TARGET
 AND DLIB ZONES FOR ASMPRINT SPECIFYING SYSOUT, OR

 ADD THE FOLLOWING JCL DD CARD TO YOUR APPLY JOBS:
 //SYSPRINT DD SYSOUT=*,LRECL=133,RECFM=FBA



MA

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

Re: SMPE assemble

[Field, Alan C.]

Check the DDDEF for SYSPRINT. I seem to recall mine has LRECL(121)

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Mark Pace
Sent: Friday, May 21, 2010 09:08 
To: IBM-MAIN@bama.ua.edu
Subject: Re: SMPE assemble

I have the correct PARM.  The problem must be with not having the
correct
JCL to provide for the output of the GOFF data.

On Fri, May 21, 2010 at 10:02 AM, Mary Anne Matyaz
wrote:

> Mark,
> JES2 1.11 requires the parms GOFF and LIST(133). See the program
directory
> or PSP bucket. (http://www-01.ibm.com/support/docview.wss?
> uid=isg1_ZOSV1R11_ZOSGEN and find 'goff')
>
> I ran the following to update the options:
>
> //SMPCNTL  DD  *
>  SET BOUNDARY(GLOBAL) .
>  UCLIN .
>  REP UTILITY(ASMA90)
>   NAME(ASMA90)
>   PARM(XREF(SHORT),NOLIST,DECK,NOOBJECT,GOFF,LIST(133)).
>  ENDUCL .
>
> Mary Anne
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317

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

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

Re: very strange ISHELL behaviour

[Jim McAlpine]

On Fri, May 21, 2010 at 2:56 PM, J. D. Cassidy  wrote:

> Jim,
>
>
> I am also running a 1.11 system (ADCD) and I do NOT have the editing
> problems that seem to plaguing you.
>
> Here is a RACF display of IBMUSER:
>
> Thanks for that but there's nothing obvious in there.  Another symptom I've
discovered is that if I enter an unrecognized character such as a "?" in the
non-IBMUSER entry panel to ISHELL I get -

.-.
| Errno=86x The function is not implemented; Reason=052C04DC. |
| Press Enter to continue.|
'-'
If I do that from the IBMUSER user I get no message whatsoever.  Also, from
IBMUSER "options" or "setup" dropdown menus I can't open any of the options
windows.

Ahhh

Jim McAlpine

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

Re: very strange ISHELL behaviour

[Jim McAlpine]

On Fri, May 21, 2010 at 3:15 PM, Jim McAlpine wrote:

>  On Fri, May 21, 2010 at 2:56 PM, J. D. Cassidy wrote:
>
>> Jim,
>>
>>
>> I am also running a 1.11 system (ADCD) and I do NOT have the editing
>> problems that seem to plaguing you.
>>
>> Here is a RACF display of IBMUSER:
>>
>
This system is actually a z/OS 1.11 system running on the Dallas RDP
facility.  Is anyone else running z/OS 1.11 at Dallas that could try this
out.

Jim McAlpine

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

Re: SMPE assemble

[Mark Pace]

Thanks, Mary -

Changed my SYSPRINT DD to add the LRECL and RECFM fixed the problem!

On Fri, May 21, 2010 at 10:14 AM, Mary Anne Matyaz
wrote:

> Mark, there's a mention of that as well in the bucket:
>
> ALSO, YOU NEED TO EITHER:
> SPECIFY A UNIQUE OUTPUT FILE USING THE PRINT OPERAND, (FOR
> EXAMPLE, PRINT(ASMPRINT)) AND CREATE A DDDEF IN YOUR TARGET
> AND DLIB ZONES FOR ASMPRINT SPECIFYING SYSOUT, OR
>
> ADD THE FOLLOWING JCL DD CARD TO YOUR APPLY JOBS:
> //SYSPRINT DD SYSOUT=*,LRECL=133,RECFM=FBA
>
>
>
> MA
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317

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

Re: very strange ISHELL behaviour

[Elardus Engelbrecht]

Jim McAlpine wrote:
>.-.
>| Errno=86x The function is not implemented; Reason=052C04DC. |
>| Press Enter to continue.|
>'-'

bpxmtext tells me there is no system root mounted.

Action: Mount a root file system on /.

Lizette also mentioned the root difference which could be the problem.

HTH!

Groete / Greetings
Elardus Engelbrecht

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

Re: Of interest to the Independent Contractors on the list

[Anne & Lynn Wheeler]

elardus.engelbre...@sita.co.za (Elardus Engelbrecht) writes:
> Perhaps, but AFAIK, such systems stored the year in two fields. One field was 
> used for century and another field for 2 digit year.
>
> In this case I suspect, it was stored as x'13' for 19 in one field for 
> century and 
> another field x'64' for year. In such systems, the year 2000 should be 
> stored/adjusted as x'14' and x'00'. Or perhaps fixed to have one field for 
> year.
>
> Then you get that formatting errors too resulting in 5 bytes of display 
> values...

re:
http://www.garlic.com/~lynn/2010i.html#53 Of interest to the Independent 
Contractors on the list

during old Y2K remediation thread from early 99
http://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve 
Y2K)

I reposted somebody else's contribution from an internal (CENTURY) forum
in the early 80s (discussing the upcoming Y2K problems)
http://www.garlic.com/~lynn/99.html#email841207

one of the items from above:

2.A bit of "cute" code I saw once operated on a year by loading a
byte of packed data into a register (using INSERT CHAR), then used LA
R,1(R) to bump the year.  Got into a bit of trouble when the year 196A
followed 1969.  I guess the problem is not everyone is aware of the odd
math in calendars.  People even set up new religions when they discover
new calendars (sometimes)

... snip ... 

the reference item also mentions problem that the person encountered in
Houston related to shuttle missions.

-- 
42yrs virtualization experience (since Jan68), online at home since Mar1970

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

Re: very strange ISHELL behaviour

[Jim McAlpine]

On Fri, May 21, 2010 at 3:21 PM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Jim McAlpine wrote:
> >.-.
> >| Errno=86x The function is not implemented; Reason=052C04DC. |
> >| Press Enter to continue.|
> >'-'
>
> bpxmtext tells me there is no system root mounted.
>
> Action: Mount a root file system on /.
>
> Lizette also mentioned the root difference which could be the problem.
>
> No, the root is definitely mounted and I can see it even from IBMUSER like
this -

EUID=0   /
  Type  Filename
_ Dir   .
_ Dir   ..
_ Dir   ...
_ File  .sh_history
_ Dir   .ssh
_ Syml  £SYSNAME
_ Syml  £VERSION
_ Syml  bin
_ Dir   Daemon
_ Syml  dev
_ Dir   domino1
_ Dir   domino2
_ Dir   domino3
_ Dir   domino4
_ Dir   domino5
_ Dir   domino6
_ Syml  etc
_ Dir   java
_ File  jims

and I can browse the file .sh_history above but I can't edit it from
IBMUSER.

Jim McAlpine

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

Re: SMPE assemble

[Paul Gilmartin]

On Fri, 21 May 2010 09:53:11 -0400, Mark Pace wrote:
>
> PRINT DD NAME   ===> SYSPRINT (Name of PRINT DD
>
> PARM===> XREF(SHORT),DECK,NOOBJECT,GOFF,LIST(133),OPTABLE(UNI)
>
>
>Being still fairly new SMPE I'm not sure if the problem is that I need a RC
>value of 4 not 0  Or the GOFF parameter is a problem, or I've left some DD
>statement out of my Apply JCL to cover the GOFF output.  Anyone have a
>suggestion on what maybe wrong?
>
Is SYSPRINT specified in a JCL DD or in UCLIN DDDEF?

In either case, is it possible to specify LRECL=133 explicitly.

If the assembler is supplying LRECL by default, it should respect
the LIST(133) for SYSPRINT.  But is this likely to be hostile to
other utilities called by SMP/E.  ISTR that the first utility invoked
by SMP/E may set the LRECL for SYSPRINT, and HLASM inherits an
adverse value by DCB merge.  But other utilities (IEBCOPY?) may
be hostile to LRECL=133.

Why do you need GOFF, anyway?

-- gil

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

Re: very strange ISHELL behaviour

[Lizette Koehler]

So what are the permissions for IBMUSER for ROOT?

Is it possible that IBMUSER does not have authority at root level?  I think 
that the permissions are inherited down the file structure.  So maybe somewhere 
between the ROOT and your file the permissions are not what you expect?

Lizette




>
>> Jim McAlpine wrote:
>> >.-.
>> >| Errno=86x The function is not implemented; Reason=052C04DC. |
>> >| Press Enter to continue.|
>> >'-'
>>
>> bpxmtext tells me there is no system root mounted.
>>
>> Action: Mount a root file system on /.
>>
>> Lizette also mentioned the root difference which could be the problem.
>>
>> No, the root is definitely mounted and I can see it even from IBMUSER like
>this -
>
>EUID=0   /
>  Type  Filename
>_ Dir   .
>_ Dir   ..
>_ Dir   ...
>_ File  .sh_history
>_ Dir   .ssh
>_ Syml  £SYSNAME
>_ Syml  £VERSION
>_ Syml  bin
>_ Dir   Daemon
>_ Syml  dev
>_ Dir   domino1
>_ Dir   domino2
>_ Dir   domino3
>_ Dir   domino4
>_ Dir   domino5
>_ Dir   domino6
>_ Syml  etc
>_ Dir   java
>_ File  jims
>
>and I can browse the file .sh_history above but I can't edit it from
>IBMUSER.
>

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

Re: SMPE assemble

[Daniel Allen]

I had to specific LRECL=137 on the SYSPRINT DD to get it to work.

On Fri, May 21, 2010 at 7:35 AM, Paul Gilmartin wrote:

> On Fri, 21 May 2010 09:53:11 -0400, Mark Pace wrote:
> >
> > PRINT DD NAME   ===> SYSPRINT (Name of PRINT DD
> >
> > PARM===>
> XREF(SHORT),DECK,NOOBJECT,GOFF,LIST(133),OPTABLE(UNI)
> >
> >
> >Being still fairly new SMPE I'm not sure if the problem is that I need a
> RC
> >value of 4 not 0  Or the GOFF parameter is a problem, or I've left some DD
> >statement out of my Apply JCL to cover the GOFF output.  Anyone have a
> >suggestion on what maybe wrong?
> >
> Is SYSPRINT specified in a JCL DD or in UCLIN DDDEF?
>
> In either case, is it possible to specify LRECL=133 explicitly.
>
> If the assembler is supplying LRECL by default, it should respect
> the LIST(133) for SYSPRINT.  But is this likely to be hostile to
> other utilities called by SMP/E.  ISTR that the first utility invoked
> by SMP/E may set the LRECL for SYSPRINT, and HLASM inherits an
> adverse value by DCB merge.  But other utilities (IEBCOPY?) may
> be hostile to LRECL=133.
>
> Why do you need GOFF, anyway?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Daniel Allen | Serena Software, Inc. | Senior Systems Programmer - Mainframe
Services
Phone: 1-800-457-3736x11241

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

Re: very strange ISHELL behaviour

[Elardus Engelbrecht]

Jim McAlpine wrote:
> No, the root is definitely mounted and I can see it even from IBMUSER like
this -

>and I can browse the file .sh_history above but I can't edit it from IBMUSER.

Ok. One last go before you open a PMR. Exactly WHAT is called for the 
program associated with the command 'e'?

Are the IBMUSER loadlibraries the same as the other ids?

What are your SYS1.SBPX* allocations to both these ids?

Anything else, I think a PMR is your avenue. Sorry

Groete / Greetings
Elardus Engelbrecht

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

Re: very strange ISHELL behaviour

[Jim McAlpine]

On Fri, May 21, 2010 at 3:38 PM, Lizette Koehler wrote:

> So what are the permissions for IBMUSER for ROOT?
>
> Is it possible that IBMUSER does not have authority at root level?  I think
> that the permissions are inherited down the file structure.  So maybe
> somewhere between the ROOT and your file the permissions are not what you
> expect?
>
> Lizette
>

IBMUSER is a superuser with uid=0.  Doesn't that mean it can do anything to
anything ?

Jim McAlpine

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

Re: z/OS file system and some Friday thoughts

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Thomas Berg
Sent: Friday, May 21, 2010 8:03 AM
To: IBM-MAIN@bama.ua.edu
Subject: z/OS file system and some Friday thoughts




Am I an idiot or just a typical programmer ?  :)



And there is a difference?



Regards,
Steve Thompson

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

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[Chris Mason]

Nick

It's ironic that there should be a thread raging currently in the ASSEMBLER-
LIST and attracting the attention of many of the "usual suspects" prominent in 
this list which concerns how references should be handled and here we have 
an example of most decidedly how *not* to handle references - that is 
practically to have none at all! Well, at least there's a Subject line and - 
with 
some effort which must be expended by everyone who might take an interest -
that does eventually lead to an understanding of what this was all about.

Just to bring everyone on board, here are the first and last post from the 
original thread - together with the dates in case anyone wanted to bother 
researching the intervening "tangents":



Subject: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

-

From: "Mark T. Regan Date: Wed, 25 Feb 2009 10:38:53 -0800

At my site we are getting ready to upgrade from z/OS v1.9 to v1.10. I have 
noticed that 3270 customizable screen sizes (i.e. 65x200 or 60x132) isn’t 
working with ISPF (ISPF 6.0) on z/OS v1.10. I get defaulted to a MOD2 screen 
size. Native TSO picks up the large screen size and NetView v5.3 on the same 
z/OS v1.10 system also works okay with the large screen size, so I think the 
issue is with ISPF. Any help would be appreciated.

-

From: "Mark T. Regan Date: Mon, 2 Mar 2009 12:18:33 -0800

I have leaned that officially ISPF only supports 62 x 160. In the ISPF Users 
Guide Volume II, section 2.1.2 Terminal characteristics, there is a note that 
says "ISPF supports screen sizes from 24 x 80 characters to 62 x 160 
characters". When I changed to 62 x 160 it does work. I then tried 65 x 160 
and it still works.

So for ISPF on z/OS v1.10, it looks like a screen size loophole that allowed 
you 
to go to 200 columns has been closed.

>/quote>

Despite the fact I did actually contribute to this thread - dealing with a 
couple 
of tangents - I did *not* remember when it happened. So, I thought maybe it 
was some topic that arose in the last few months. However, after browsing 
the archives back to December without success, I recalled that "Google was 
my friend" and there it was, February and March 2009 - is this a record for 
reviving a thread?

At this point I decided that just maybe - shock, horror, reach for the smelling 
salts - an answer could be found in the ISPF documentation:



| 2. ISPF supports a minimum screen size of 24 rows and 80 
| columns. The maximum screen width is 160 columns.



This was taken from section 2.1.2, "Terminal characteristics" in Interactive 
System Productivity Facility (ISPF), User's Guide Volume II, z/OS Version 1 
Release 11.0, SC34-4823-09.

Interestingly enough, those "revision bars" threaten to "muddy the water" so I 
was obliged to go back a level in order to see what was stated before.

The apparently equivalent statement in spite of the number change is the 
following:



1. ISPF supports screen sizes from 24 x 80 characters to 62 x 160 characters.



Ok, there's a new "1", so what is it:



| 1. Primary and alternate screen dimensions are determined by 
| the VTAM logmode and the capabilities of the terminal or 
| terminal emulator. These values can be displayed by the ISPF 
| ENVIRON settings panel and issuing the QUERY request.



In other words, the ISPF authors thought that the user ought to be reminded 
where the presentation space, aka "screen", dimensions come from - and they 
got it wrong - in the sense that they did not really cover the topic with a 
suitable degree of accuracy. The "presentation space dimensions" can be set 
either "in stone" in a  mode table entry or they can be set by the, typically 
these days, emulator customisation together with a mode table entry which in 
effect says "go and ask the 'workstation' what dimensions the 3270 display 
window would like to have today".

So, getting back to the original post, the manual has it: ISPF is prepared to 
support presentation of information in its 3270 display panels up to 160 
characters in width. It is implied by omission that ISPF is prepared to support 
panels of indefinite depth starting with V1R11 changing from a maximum of 62 
previously.

Oddly enough the authors did not consider this implied enhancement deserved 
comment in the "Summary of Changes" which appears simply to be copied 
unchanged into all ISPF manuals.

While composing my response, I got back to the original thread at this point - 
with the results given above. I see I got involved later but I really should 
have 
jumped in at the start with an answer to Mark Regan's question:

>...> so I think the issue is with ISPF. Any help would be appreciated.

with "Erm, the manual can also be *helpful*!"

One of the posts from a Peter Farley indicated that he has/had a magic 
version of ISPF which supported 65x200!

And when I finally got through all the posts, I discovered that Mark Regan, 
after having opened up a formal problem with IBM, was - one hopes politely - 
reminded actuall

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[Chris Mason]

The TSO "environment" was most usefully "updated" in V1R11 at least with 
the "logon here" function - long available in VM, it has to be said. Perhaps it 
was some manifestation of "rigor mortis"!

Chris Mason

On Thu, 20 May 2010 11:04:58 -0400, zMan  
wrote:

>My bad -- I meant that the entire environment is pretty stable and not
>updated; it seems that it's the ISPF layer that is having trouble here, not
>TSO itself. I realize they're different, but they're *almost* synonymous. My
>point remains: where's the win for IBM?
>
>On Thu, May 20, 2010 at 9:59 AM, Thompson, Steve <
>steve_thomp...@stercomm.com> wrote:
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>> Behalf Of zMan
>> Sent: Thursday, May 20, 2010 8:36 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10
>>
>> On Thu, May 20, 2010 at 4:48 AM, Nick Jones 
>> wrote:
>>
>> > Mark,
>> > Sorry to pick up on this old post but we have just upgraded from z/OS
>> 1.9
>> > to
>> > z/OS 1.11 and, like you, take advantage of screen sizes in excess of
>> > 62x160.
>> >
>> > We have the same problem with ISPF 6.1 as you had with ISPF 6.0. i.e.
>> > TSO obeys the terminal setting of 86x190, as does SELCOPY/i when run
>> > directly from TSO, but ISPF switches to MOD 2.
>> >
>> > Did you manage to get a solution (or an explination) from IBM ?
>> >
>>
>> What's to explain? TSO is old and grotty, and supporting random screen
>> sizes
>> in fullscreen apps is a pain. By no means impossible, of course, but a
>> lot
>> of work. Will making that investment sell more TSO or keep sites from
>> migrating off? Unlikely... so why would they do it?
>>
>> Unpleasant reality, but reality nonetheless.
>> 
>>
>> Let me see if I have this right. TSO supports the huge screen size. So
>> it is old and grotty.
>>
>> ISPF has a problem with it and forces MOD2. But it is OK since it
>> supports the workstation model with GUI.
>>
>> The problem with ISPF, according to one of the guys here who does more
>> stuff with ISPF than I do, is that ISPF supports a smaller size --
>> because for whatever reason, they [ISPF] changed things to use a smaller
>> workspace/buffer/screen size/addressing (it was one of those or some
>> combination). IIRC, an earlier release of ISPF *WAS* supporting the
>> larger sizes (was that z/OS 1.6?).
>>
>> But, TSO supports the humungous screen sizes -- so it is old grotty and
>> well, dead.
>>
>> Reality, not perception.
>>
>> Regards,
>> Steve Thompson

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

gif,doc,html - LRECL's

[Sumi, Joseph J. (CMS/CTR) (CTR)]

I xfer files that have .gif, .doc, .html, .pdf extensions from my pc to
a mainframe HFS to be hosted by a mainframe webserver. I have to move
these around to get them where I want. I copy them out of my HFS to a
sequential file and then moved to a different system to be copied back
to a different HFS. The lrecl and blksize are automatically determined
when copying from ISHELL and everything works out fine but I would like
to skip some steps and copy from my PC to a pre-allocated sequential
file directly.

My question is, what is the rule of thumb for determining LRECLs for
file types like this ?? How do I know what they should be if I am
pre-allocating the dataset that they will be uploaded to ?

xxx.DOC PSVB automatically set --> 32756  32760
xxx.GIF PSVB automatically set --> 18443  27998
xxx.HTMLPSVB automatically set --> 26412  27998

Rgrds, Joseph Sumi

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

Re: IBM to announce new MF's this year

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


Anne & Lynn Wheeler  writes:
> and old email about numerical intensive clustering scalup ... with LLNL
> and other gov. labs (just hrs before the effort was transferred and we
> were told we couldn't work on anything with more than four processors).
> http://www.garlic.com/~lynn/2006x.html#email920129
>
> then press item a couple weeks later
> http://www.garlic.com/~lynn/2001n.html#6000clusters1 17feb92
> and then 
> http://www.garlic.com/~lynn/2001n.html#6000clusters2 19jun92

re:
http://www.garlic.com/~lynn/2010i.html#61 IBM to announce new MF's this year

the 19jun92 press item includes quote about clustering coming as
complete surprise to the company.

the indifference to clustering also earlier had contributed to my wife
not remaining very long in POK (responsible for mainframe
loosely-coupled architecture); that and ongoing battles with the sna
organization that the loosely-coupled operations needed to go thru vtam.

nearly all the top supercomputers are now clusters (although they may be
various kinds of clusters involving clustered combinations of smaller
units that have various kinds of shared memory)
http://www.top500.org/

LLNL wiki page:
http://en.wikipedia.org/wiki/Lawrence_Livermore_National_Laboratory

supercomputer wiki page
http://en.wikipedia.org/wiki/Supercomputer

-- 
42yrs virtualization experience (since Jan68), online at home since Mar1970

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

z/OS 1.11 Dallas RDP system request (was very strange ISHELL behaviour)

[Jim McAlpine]

Anyone on the list have access to a z/OS 1.11 Dallas RDP system.  If so
could you do me a favour and log on to IBMUSER and select the "OS" option
(ISHELL) from the primary menu and try to edit the .sh_history file in the
root directory and let me know what happens.

TIA

Jim McAlpine

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

Re: gif,doc,html - LRECL's

[Paul Gilmartin]

On Fri, 21 May 2010 11:49:50 -0400, Sumi, Joseph J. (CMS/CTR) (CTR) wrote:

>I xfer files that have .gif, .doc, .html, .pdf extensions from my pc to
>a mainframe HFS to be hosted by a mainframe webserver. I have to move
>these around to get them where I want. I copy them out of my HFS to a
>sequential file and then moved to a different system to be copied back
>to a different HFS. The lrecl and blksize are automatically determined

Is it not possible to go direct from HFS to HFS and omit the
legacy data set waystation?

>when copying from ISHELL and everything works out fine but I would like
>to skip some steps and copy from my PC to a pre-allocated sequential
>file directly.
>
>My question is, what is the rule of thumb for determining LRECLs for
>file types like this ?? How do I know what they should be if I am
>pre-allocating the dataset that they will be uploaded to ?
>
>xxx.DOC PSVB automatically set --> 32756  32760
>xxx.GIF PSVB automatically set --> 18443  27998
>xxx.HTMLPSVB automatically set --> 26412  27998
>
If you must, I'd suggest using "pax -w ..." with output directed
to a legacy data set to unload the HFS files en masse; transfer
that data set to the different system, and use "pax -r ..." to
reload them.  No more worry about LRECL, RECFM.

-- gil

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

Re: gif,doc,html - LRECL's

[Sumi, Joseph J. (CMS/CTR) (CTR)]

>Is it not possible to go direct from HFS to HFS and omit the
>legacy data set waystation?
Unfortunately, no, it is not possible right now.

>I'd suggest using "pax -w ..."
I want to totally bypass system#1/hfs#1 ... I want to IND$FILE to a
seq on system#2 and then OPUT to hfs#2. Looking to figure out what DCB
to use for the seq files on system#2. The PAX method looks to still
involve system#1.


Rgrds, Joseph Sumi






-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Friday, May 21, 2010 12:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: gif,doc,html - LRECL's

On Fri, 21 May 2010 11:49:50 -0400, Sumi, Joseph J. (CMS/CTR) (CTR)
wrote:

>I xfer files that have .gif, .doc, .html, .pdf extensions from my pc to
>a mainframe HFS to be hosted by a mainframe webserver. I have to move
>these around to get them where I want. I copy them out of my HFS to a
>sequential file and then moved to a different system to be copied back
>to a different HFS. The lrecl and blksize are automatically determined

Is it not possible to go direct from HFS to HFS and omit the
legacy data set waystation?

>when copying from ISHELL and everything works out fine but I would like
>to skip some steps and copy from my PC to a pre-allocated sequential
>file directly.
>
>My question is, what is the rule of thumb for determining LRECLs for
>file types like this ?? How do I know what they should be if I am
>pre-allocating the dataset that they will be uploaded to ?
>
>xxx.DOC PSVB automatically set --> 32756  32760
>xxx.GIF PSVB automatically set --> 18443  27998
>xxx.HTMLPSVB automatically set --> 26412  27998
>
If you must, I'd suggest using "pax -w ..." with output directed
to a legacy data set to unload the HFS files en masse; transfer
that data set to the different system, and use "pax -r ..." to
reload them.  No more worry about LRECL, RECFM.

-- gil

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

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

SMS QUESTION

[esmie moo]

Good Morning Gentle Readers,
 
I am in the processing of allocating a SC & SG for several new aliases in SMS.  
The user doesn't want this particular STORAGE GROUP to have migration.  This 
sounds okay however since there is no DFHSM in this partition is it necessary 
to pay particular attention or modify the MANAGEMENT class CONSTRUCT & ACS 
routines?  The archiving tool in this partitioin is CA-DISK.
 
Thanks in advance 



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

Re: SMS QUESTION

[Michael Wickman]

You might want to consider the management class activity if there is a 
possibility the data/application could move to a lpar with DFHSM.  If that's 
unlikely, then it's not necessary.



Mike Wickman


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
esmie moo
Sent: Friday, May 21, 2010 11:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: [IBM-MAIN] SMS QUESTION

Good Morning Gentle Readers,
 
I am in the processing of allocating a SC & SG for several new aliases in SMS.  
The user doesn't want this particular STORAGE GROUP to have migration.  This 
sounds okay however since there is no DFHSM in this partition is it necessary 
to pay particular attention or modify the MANAGEMENT class CONSTRUCT & ACS 
routines?  The archiving tool in this partitioin is CA-DISK.
 
Thanks in advance 



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

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

Re: SMS QUESTION

[esmie moo]

Michael,
 
Thank you.  No, there is no plans to have DFHSM in this partition.  The client 
is satisfied with CA-ALLOCATE/CA-DISK.
 
Thanks.

--- On Sat, 5/22/10, Michael Wickman  wrote:


From: Michael Wickman 
Subject: Re: SMS QUESTION
To: IBM-MAIN@bama.ua.edu
Received: Saturday, May 22, 2010, 4:42 AM


You might want to consider the management class activity if there is a 
possibility the data/application could move to a lpar with DFHSM.  If that's 
unlikely, then it's not necessary.



Mike Wickman


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
esmie moo
Sent: Friday, May 21, 2010 11:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: [IBM-MAIN] SMS QUESTION

Good Morning Gentle Readers,
 
I am in the processing of allocating a SC & SG for several new aliases in SMS.  
The user doesn't want this particular STORAGE GROUP to have migration.  This 
sounds okay however since there is no DFHSM in this partition is it necessary 
to pay particular attention or modify the MANAGEMENT class CONSTRUCT & ACS 
routines?  The archiving tool in this partitioin is CA-DISK.
 
Thanks in advance 



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

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




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

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[Edward Jaffe]

Chris Mason wrote:
The TSO "environment" was most usefully "updated" in V1R11 at least with 
the "logon here" function - long available in VM, it has to be said. Perhaps it 
was some manifestation of "rigor mortis"!
  


TSO/E also recently got password phrase support.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[Gates, Guy]

Hi,

 Just a thought. I had a user with a similar problem as he wanted to set
his screen size to 35x155 and started to fail when I installed z/OS
1.10. What we found out was that in TSOKEY00 the buffersizes were too
small to support it and when we increased them he was able to use the
larger screen size. I don't know if they changed when I installed z/OS
1.10, or if we were right at the limit of what we could use and 1.10 put
us over the buffer size. 

 We set them to:

HIBFREXT=48000,
LOBFREXT=24000,

 Sorry, but I don't remember what they were set to before we changed
them.

HTH...Guy M. Gates Jr.
TTI Z/OS Systems Programmer II
Email: guy.ga...@ttiinc.com

"z/OS - World class computing."


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

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

Re: z/OS file system and some Friday thoughts

[Roberto Halais]

Automatic QED.

On 5/21/10, Thompson, Steve  wrote:
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Thomas Berg
> Sent: Friday, May 21, 2010 8:03 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: z/OS file system and some Friday thoughts
>
> 
>
>
> Am I an idiot or just a typical programmer ?  :)
>
> 
>
> And there is a difference?
>
> 
>
> Regards,
> Steve Thompson
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
"It is no measure of health to be well adjusted to a profoundly sick
society." -Krishnamurti

"I am as you, in you, for you. One as you in all, as all, forever. My call
is your call."

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

Re: FTP Get Blocked by ISPF EDIT

[Edward Jaffe]

Hunkeler Peter (KIUP 4) wrote:
Ed: How happy would you be if your automated ftp process 
successfully replaces the member someone else is editing at

the same time. A single SAVE and your successfull ftp isn't
worth a dime anymore.
  


That is a different scenario entirely. My situation is not a remote PUT. 
Rather, my situation is a remote GET that fails simply because someone, 
perhaps even someone without UPDATE/SAVE access to the library, decided 
to bring the member up under ISPF EDIT.


Unless I'm missing something, it seems like any "Joe Blow" goofing 
around and/or with malicious intent can exploit this behavior to "break" 
any process involving remote FTP GET.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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

Re: gif,doc,html - LRECL's

[Terry Sambrooks]

Hi Joseph,

With regard to your desire to move gifs, docs, and HTML around.

Like Paul, I would query the need for the z/OS Sequential file at all.

Instead of IND$FILE, FTP is more useful here.

I have used both the Windows supplied FTP, and GlobalSCAPE's CuteFTP to
perform this function transmitting direct from the PC hard drive to the
target HFS folder of my choice.

I tend to keep the master copies of such items on the PC as it is more
convenient for a variety of reasons.

In the context of FTP it should be possible to ship from one z/OS System to
another all things being equal.

Kind Regards - Terry
 
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK
 
Reg : 3767263
 
Outgoing e-mails have been scanned, but it is the recipients responsibility
to ensure their anti-virus software is up to date.
 
 


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

Re: gif,doc,html - LRECL's

[Sumi, Joseph J. (CMS/CTR) (CTR)]

FTP works fine to system1/hfs1.

I do not have the ability to do that with system2/hfs2 at the moment.

Rgrds, Joseph Sumi






-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Terry Sambrooks
Sent: Friday, May 21, 2010 12:58 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: gif,doc,html - LRECL's

Hi Joseph,

With regard to your desire to move gifs, docs, and HTML around.

Like Paul, I would query the need for the z/OS Sequential file at all.

Instead of IND$FILE, FTP is more useful here.

I have used both the Windows supplied FTP, and GlobalSCAPE's CuteFTP to
perform this function transmitting direct from the PC hard drive to the
target HFS folder of my choice.

I tend to keep the master copies of such items on the PC as it is more
convenient for a variety of reasons.

In the context of FTP it should be possible to ship from one z/OS System
to
another all things being equal.

Kind Regards - Terry
 
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK
 
Reg : 3767263
 
Outgoing e-mails have been scanned, but it is the recipients
responsibility
to ensure their anti-virus software is up to date.
 
 


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

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

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[Edward Jaffe]

Gates, Guy wrote:

We set them to:

HIBFREXT=48000,
LOBFREXT=24000,
  


Having small values here results in hang conditions writing large 
screens, not a 24x80 (aka Mod2) appearance under ISPF.


FWIW, our values are set thusly:

HIBFREXT=96000,
LOBFREXT=48000,

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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

DFHSM Doc on when it resets the "dataset changed flag(bit)"

[Gibney, Dave]

I can't find a definitive statement in the DFhsm books as to when and
how this flag is reset when backing up. Or does it set it at all?

For historical (hysterical) reasons, we do both FDR and HSM backups. FDR
for the hypothetical:) DR and HSM for user convenience. 
Awhile back, we made a markedly unsuccessful attempt to switch
completely to FDR. We've lost to Systems people since and are unlikely
to try again.

Anyway, FDR has a setting to not reset the flag in a mixed environment
like this. I thought DFHSM would reset it but it appears that the flag
is not being reset by anything and I'm getting an additional and
unneeded back-up by each FDR run. HSM appears to be following the SMS
definition for back-up frequency.

Ibmlink SIS didn't find anything, but crafting a proper search argument
for this is problematic. Data and changed and flag appear frequently :)

Dave Gibney
Information Technology Services
Washington State University

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

Re: very strange ISHELL behaviour

[Mark Zelden]

Perhaps an initial edit macro set (under that applied) causing problems? 

You could try renaming / deleting BPXWPROF from the ISPPROF data set
and see what happens.

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

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

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Gates, Guy
> 
> Hi,
> 
>  Just a thought. I had a user with a similar problem as he wanted to
set
> his screen size to 35x155 and started to fail when I installed z/OS
> 1.10. What we found out was that in TSOKEY00 the buffersizes were too
> small to support it and when we increased them he was able to use the
> larger screen size. I don't know if they changed when I installed z/OS
> 1.10, or if we were right at the limit of what we could use and 1.10
put
> us over the buffer size.
> 
>  We set them to:
> 
> HIBFREXT=48000,
> LOBFREXT=24000,
> 
>  Sorry, but I don't remember what they were set to before we changed
> them.

On z/OS 1.11 we have

HIBFREXT=6600,
LOBFREXT=3300,

with which I run 62x160 without problems.

   -jc-

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

Re: FTP Get Blocked by ISPF EDIT

[Patrick Lyon]

On Fri, 21 May 2010 09:56:27 -0700, Edward Jaffe 
 wrote:

>Unless I'm missing something, it seems like any "Joe Blow" goofing
>around and/or with malicious intent can exploit this behavior to "break"
>any process involving remote FTP GET.
>
>--

Edward - Then "any Joe Blow" should not have read access to the said 
dataset.

This is no more of an issue than a sequential file being updated.  You cannot 
GET an edited sequential file either.  The file is being used for output, the 
user 
has exclusive control of that data at that time.  It is called data integrity, 
which is the backbone of a mainframe.

How about this:  Say this restriction did not exist.  Say someone has the 
member open in edit attempting to change it.  You FTP in and do a GET, your 
FTP finishes.  Seconds after the member is saved by the user.  You have old 
data!  Is that really what you wanted in the first place?

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

Re: SMS QUESTION

[John H Kington]

Esmie,

CA-Disk can be setup to honor the management class attributes or ignore them by 
setting a parameter in SYSPARMS parmlib member. Since the DSL gave us 
everything we needed to manage our datasets, we chose to ignore the management 
class in our shop but we still assign management class in case we ever decide 
to switch to DFHSM.

As long as the dasd in the storage group is not shared with any other lpar 
(system) that has DFHSM running and you do not run the archive command against 
the volumes in the storage group, management class is of no consequence. Not 
setting the management class will result in the dataset getting the default 
management class specified in you sms configuration. This could be a big clean 
up effort if you ever decided to switch to DFHSM or have CA-Disk use the 
management class attributes to manage the datasets in the storage group.

Regards,
John

>Michael,
>
>Thank you.  No, there is no plans to have DFHSM in this partition.  The client 
>is satisfied with CA-ALLOCATE/CA-DISK.
>
>Thanks.
>
>>
>>From: Michael Wickman 
>>Subject: Re: SMS QUESTION
>>To: IBM-MAIN@bama.ua.edu
>>Received: Saturday, May 22, 2010, 4:42 AM
>>
>>
>>You might want to consider the management class activity if there is a 
>>possibility the data/application could move to a lpar with DFHSM.  If that's 
unlikely, then it's not necessary.
>>
>>
>>
>>Mike Wickman
>>

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

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

Re: SMS QUESTION

[John Dawes]

I am confused.  Doesn't the MANAGEMENT class kick in even there is no DFHSM in 
place.  For example the EXPIRE after & Retention Limit is this only relevant if 
DFHSM is installed?  How about if there is FDR instead? What would control the 
management of these dsns :
 
Expire after Days Non-usage  . : 
Expire after Date/Days . . . . : 
Retention Limit  . . . . . . . : 



--- On Sat, 22/5/10, Michael Wickman  wrote:


From: Michael Wickman 
Subject: Re: SMS QUESTION
To: IBM-MAIN@bama.ua.edu
Received: Saturday, 22 May, 2010, 2:42 AM


You might want to consider the management class activity if there is a 
possibility the data/application could move to a lpar with DFHSM.  If that's 
unlikely, then it's not necessary.



Mike Wickman


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
esmie moo
Sent: Friday, May 21, 2010 11:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: [IBM-MAIN] SMS QUESTION

Good Morning Gentle Readers,
 
I am in the processing of allocating a SC & SG for several new aliases in SMS.  
The user doesn't want this particular STORAGE GROUP to have migration.  This 
sounds okay however since there is no DFHSM in this partition is it necessary 
to pay particular attention or modify the MANAGEMENT class CONSTRUCT & ACS 
routines?  The archiving tool in this partitioin is CA-DISK.
 
Thanks in advance 



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

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





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

Re: FTP Get Blocked by ISPF EDIT

[Joel C. Ewing]

On 05/21/2010 11:59 AM, Edward Jaffe wrote:
> Hunkeler Peter (KIUP 4) wrote:
>> Ed: How happy would you be if your automated ftp process successfully
>> replaces the member someone else is editing at
>> the same time. A single SAVE and your successfull ftp isn't
>> worth a dime anymore.
>>   
> 
> That is a different scenario entirely. My situation is not a remote PUT.
> Rather, my situation is a remote GET that fails simply because someone,
> perhaps even someone without UPDATE/SAVE access to the library, decided
> to bring the member up under ISPF EDIT.
> 
> Unless I'm missing something, it seems like any "Joe Blow" goofing
> around and/or with malicious intent can exploit this behavior to "break"
> any process involving remote FTP GET.
> 

So how is MVS supposed to distinguish between an instance of someone who
shouldn't be editing the data or has no intention of saving vs. someone
who is editing critical changes that must be saved before the next
remote GET should be allowed to proceed to avoid sending the remote user
erroneous data?

If it is more important that the GET have minimal possibility of failure
than to get the absolutely latest update, the best option may be to make
a mirror copy of the data at an agreed on point in time into a dataset
with restricted READ access and use that for the actual FTP transfer.

-- 
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org

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

Re: DFHSM Doc on when it resets the "dataset changed flag(bit)"

[Staller, Allan]

IIRC, DFHSM will reset the change bit on DS backup. I have not heard of
any way to change this.

DFHSM *DOES* have an option to reset/not reset the changed bit on DS
dump.

HTH,


I can't find a definitive statement in the DFhsm books as to when and
how this flag is reset when backing up. Or does it set it at all?


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

Re: FTP Get Blocked by ISPF EDIT

[Patrick Lyon]

On Fri, 21 May 2010 12:25:00 -0500, Joel C. Ewing  
wrote:

>If it is more important that the GET have minimal possibility of failure
>than to get the absolutely latest update, the best option may be to make
>a mirror copy of the data at an agreed on point in time into a dataset
>with restricted READ access and use that for the actual FTP transfer.
>

I think a better option would be put the data on some Micro$oft server.  







Sorry, couldn't resist.  :)  It is Friday after all...

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

Re: FTP Get Blocked by ISPF EDIT

[Charles Mills]

"Old data" is not a problem. Had he FTPed two minutes earlier he would have
gotten "old" data. All data is "old" in that it may change at some point in
the future. The "problem" is only if the user does a "preliminary" save --
being cautious after having made half of his changes -- and you GET a
version that was never intended to be integral.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Patrick Lyon
Sent: Friday, May 21, 2010 10:23 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FTP Get Blocked by ISPF EDIT

On Fri, 21 May 2010 09:56:27 -0700, Edward Jaffe 
 wrote:


How about this:  Say this restriction did not exist.  Say someone has the 
member open in edit attempting to change it.  You FTP in and do a GET, your 
FTP finishes.  Seconds after the member is saved by the user.  You have old 
data!  Is that really what you wanted in the first place?

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

DFSORT - ICETOOL Question

[George.William]

Group

 

It's Friday and my brain is NOT working.  I'm having a heck of a time
putting together an ICETOOL step.

The output is every record in dataset 1 that has a matching key in
dataset 2. 

 

The 2 datasets have different LRECLs and the key is in different
positions.

   DS1:   LRECL=400   KEY=7 for a length of 13  (note: 7 is column
position, not offset)

   DS2:   LRECL=80 KEY=2 for a length of 13

OUTPUT is all records in DS1 that have a matching key in DS2.

 

I've looked at the SELECT and SPLICE examples in the DFSORT guide and
here is what I have but I'm guessing I'm way off base.

I'm getting records from both input datasets into the output where I
require only the records from DS1.

Thanks for any insights!

Bill 

 

//* -- 

//* FIND MATCHING RECORDS  

//* - KEYS IN DIFFERNT POSITIONS   

//* -- 

//FINDREC EXEC  PGM=ICETOOL

//TOOLMSG DD SYSOUT=*  

//DFSMSG  DD SYSOUT=*  

//DS1 DD DSN=,DISP=SHR 

//DS2 DD DSN=,DISP=SHR   

//T1  DD DSN=,

//   DISP=(MOD,CATLG,KEEP),UNIT=SYSDA, 

//   SPACE=(CYL,(100,10),RLSE),

//   DCB=(RECFM=FB,LRECL=400,BLKSIZE=0)

//OUT DD DSN=, 

//   DISP=(MOD,CATLG,KEEP),UNIT=SYSDA, 

//   SPACE=(CYL,(100,10),RLSE),

//   DCB=(RECFM=FB,LRECL=400,BLKSIZE=0)

//TOOLIN  DD * 

  COPY FROM(DS1) TO(T1) USING(CTL1)

  COPY FROM(DS2) TO(T1) USING(CTL2)

  SPLICE FROM(T1) TO(OUT) ON(6,13,CH) WITH(6,13)   

/* 

//CTL1CNTL DD *

  OUTREC BUILD=(1:1,400)   

/* 

//CTL2CNTL DD *

  OUTREC BUILD=(6:1,80)

/* 

 

Bill George  
FTB | Tax Systems and Applications Bureau | BETS Interface Team
Office: 916.845.6459 | ms: L-210 | location: LA2B-B-5-02 
email: william.geo...@ftb.ca.gov  

 

__
CONFIDENTIALITY NOTICE: This email from the State of California is for the sole 
use of the intended recipient and may contain confidential and privileged 
information. Any unauthorized review or use, including disclosure or 
distribution, is prohibited. If you are not the intended recipient, please 
contact the sender and destroy all copies of this email.

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

Re: DFHSM Doc on when it resets the "dataset changed flag(bit)"

[Gibney, Dave]

That's what I thought, yet my FDR incrementals back-up the datasets
every run, changed or not. 

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Staller, Allan
> Sent: Friday, May 21, 2010 10:38 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DFHSM Doc on when it resets the "dataset changed
> flag(bit)"
> 
> IIRC, DFHSM will reset the change bit on DS backup. I have not heard
of
> any way to change this.
> 
> DFHSM *DOES* have an option to reset/not reset the changed bit on DS
> dump.
> 
> HTH,
> 
> 
> I can't find a definitive statement in the DFhsm books as to when and
> how this flag is reset when backing up. Or does it set it at all?
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: Amazing article.

[Hylton Tom P]

FWIW Those aren't my comments.  Those were the ones I was responding to,
but I think the quote got mangled.

I just posted a link to an article that indicated the same as you are
saying:
http://searchdatacenter.techtarget.com/news/article/0,289142,sid80_gci15
08584,00.html 



-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Thursday, May 20, 2010 8:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Amazing article.

In
<4c5d185039a6a0499f76fa65ac606dbc0452d...@nct0010cp3mb04.ds.irsnet.gov>,
on 05/18/2010
   at 05:06 PM, Hylton Tom P  said:

>OS/2 is dead,

FSVO dead.

>so users were forced to migrate off.

Some were.

>Possibly some existing and "closed" applications are being in use 
>nowadays.

There's still application development.

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

SDSF Authority Change with z/OS 1.9

[Schwartz, Alan]

Hello group, I have another puzzler that I haven't solved yet.  We've
migrated from z/OS 1.7 to 1.9 and some people have lost the ability to
view output that is in held class 5. 
This doesn't seem to be affecting everyone  as there's lots of entries
in class 5 and various jobs and I've only heard from two people.
 
We're using the SDSF server with ISFPRM00 in a pds, not external
security.  Any clues how I can rectify this?  The SDSF manual is a lot
less clear on non-SAF security than it used to be.
 
Alan 

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

What am I missing on XPLINK(OSCALL(N)) ?

[Charles Mills]

I've got some C++ code. The C++ code calls several functions written in
assembler. This all works non-XPLINK. I compile it with XPL(OSCALL(N)). I
bind into a PDSE. I run it z/OS batch. The C++ code takes off and runs. I
can see that it survives several C++ method calls. The first call to one of
the assembler functions it falls on its face somewhere after leaving the C++
code and before returning. Storage has been overlaid badly enough that the
save area trace and so forth is pretty much junk. I have desk-checked the
assembler function - it's only 50 lines including lots of comments - and as
I said, it works non-XPLINK. It makes no calls although it does do a STORAGE
OBTAIN,LOC=24

 

Am I doing things generally correctly? What should I be looking for?

 

The assembler routine is defined in the C++ code as

 

extern "OS" {

myStruct  *GETG24();

}

 

It begins GETG24   EDCPRLG DSALEN=CDSALEN,BASEREG=R12 and ends with  EDCEPIL
, and once again, it works non-XPLINK.

 

Charles Mills




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

Re: DFSORT - ICETOOL Question

[Frank Yaeger]

William George wrote on 05/21/2010 10:47:54 AM:
> It's Friday and my brain is NOT working.  I'm having a heck of a time
> putting together an ICETOOL step.
>
> The output is every record in dataset 1 that has a matching key in
> dataset 2.
>
> The 2 datasets have different LRECLs and the key is in different
> positions.
>
>DS1:   LRECL=400   KEY=7 for a length of 13  (note: 7 is column
> position, not offset)
>
>DS2:   LRECL=80 KEY=2 for a length of 13
>
> OUTPUT is all records in DS1 that have a matching key in DS2.
>
>  ...

Bill,

I need some more information.

Please show an example of the records in each input file (relevant fields
only) and what you expect for output.  Explain the "rules" for getting from
input to output.  Give the starting position, length and format of each
relevant field.  Give the RECFM and LRECL of the input files.  If file1 can
have duplicates within it, show that in your example.  If file2 can have
duplicates within it, show that in your example.)

If you have the DFSORT PTF for JOINKEYS, it might be a better choice than
SPLICE.  So please run this job and show the //SYSOUT messages you receive,
so I can see what level you're at:

//S1EXEC  PGM=SORT
//SYSOUTDD  SYSOUT=*
//SORTIN DD *
RECORD
//SORTOUT DD DUMMY
//SYSINDD*
OPTION COPY
/*

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

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

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

Re: DFHSM Doc on when it resets the "dataset changed flag(bit)"

[John H Kington]

Dave,
Are you using autobackup y on your storage groups or the incremental option on 
the backvol command(s)?
Regards,
John
513-723-7527
john.king...@convergys.com

From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Gibney, 
Dave [gib...@wsu.edu]
Sent: Friday, May 21, 2010 1:16 PM
To: IBM-MAIN@bama.ua.edu
Subject: DFHSM Doc on when it resets the "dataset changed flag(bit)"

I can't find a definitive statement in the DFhsm books as to when and
how this flag is reset when backing up. Or does it set it at all?

For historical (hysterical) reasons, we do both FDR and HSM backups. FDR
for the hypothetical:) DR and HSM for user convenience.
Awhile back, we made a markedly unsuccessful attempt to switch
completely to FDR. We've lost to Systems people since and are unlikely
to try again.

Anyway, FDR has a setting to not reset the flag in a mixed environment
like this. I thought DFHSM would reset it but it appears that the flag
is not being reset by anything and I'm getting an additional and
unneeded back-up by each FDR run. HSM appears to be following the SMS
definition for back-up frequency.

Ibmlink SIS didn't find anything, but crafting a proper search argument
for this is problematic. Data and changed and flag appear frequently :)

Dave Gibney
Information Technology Services
Washington State University

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

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

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

Re: FTP Get Blocked by ISPF EDIT

[Patrick Lyon]

On Fri, 21 May 2010 10:47:38 -0700, Charles Mills  
wrote:

>"Old data" is not a problem. Had he FTPed two minutes earlier he would have
>gotten "old" data. All data is "old" in that it may change at some point in
>the future. The "problem" is only if the user does a "preliminary" save --
>being cautious after having made half of his changes -- and you GET a
>version that was never intended to be integral.
>

I beg to differ.  Any data read prior to update would not be "old" data.  It 
is "current" data at that time.  Regardless of the validity of the data.

But once again, it's Friday.  :)

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

Re: SMS QUESTION

[John H Kington]

John,
You always get a management class assigned for a sms-managed dataset. You need 
a product like DFSMShsm, CA-Disk or FDR/ABARS to take action based on the 
attributes in the management class. You might get an expiration date assigned 
to a dasd dataset if you have a retention limit but again, you need a data 
management product to take the action.

Regards,
John

I am confused.  Doesn't the MANAGEMENT class kick in even there is no DFHSM in 
place.  For example the EXPIRE after & Retention Limit is this only relevant if 
DFHSM is installed?  How about if there is FDR instead? What would control the 
management of these dsns :

Expire after Days Non-usage  . :
Expire after Date/Days . . . . :
Retention Limit  . . . . . . . :



--- On Sat, 22/5/10, Michael Wickman  wrote:


From: Michael Wickman 
Subject: Re: SMS QUESTION
To: IBM-MAIN@bama.ua.edu
Received: Saturday, 22 May, 2010, 2:42 AM


You might want to consider the management class activity if there is a 
possibility the data/application could move to a lpar with DFHSM.  If that's 
unlikely, then it's not necessary.



Mike Wickman


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
esmie moo
Sent: Friday, May 21, 2010 11:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: [IBM-MAIN] SMS QUESTION

Good Morning Gentle Readers,

I am in the processing of allocating a SC & SG for several new aliases in SMS.  
The user doesn't want this particular STORAGE GROUP to have migration.  This 
sounds okay however since there is no DFHSM in this partition is it necessary 
to pay particular attention or modify the MANAGEMENT class CONSTRUCT & ACS 
routines?  The archiving tool in this partitioin is CA-DISK.

Thanks in advance



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

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





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

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

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

Re: What am I missing on XPLINK(OSCALL(N)) ?

[Dave Day]

SNIP  

I've got some C++ code. The C++ code calls several functions written in
assembler. This all works non-XPLINK. I compile it with XPL(OSCALL(N)). I
bind into a PDSE. I run it z/OS batch. The C++ code takes off and runs. I
can see that it survives several C++ method calls. The first call to one of
the assembler functions it falls on its face somewhere after leaving the C++
code and before returning. Storage has been overlaid badly enough that the
save area trace and so forth is pretty much junk. I have desk-checked the
assembler function - it's only 50 lines including lots of comments - and as
I said, it works non-XPLINK. It makes no calls although it does do a STORAGE
OBTAIN,LOC=24

SNIP

You may have already taken this into account, but the whole thing with XPLINK 
is that it is a different linkage mechanism between modules.  If your assembler 
code expects the standard register conventions, what piece of code in the 
calling C++ would do that? 

--Dave

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

Re: DFSORT - ICETOOL Question

[Schwarz, Barry A]

Page 9 of 
http://www-947.ibm.com/systems/support/storage/software/sort/mvs/tricks/pdf/sorttrck.pdf
 has a sample of how to do this.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
George.William
Sent: Friday, May 21, 2010 10:48 AM
To: IBM-MAIN@bama.ua.edu
Subject: DFSORT - ICETOOL Question

Group



It's Friday and my brain is NOT working.  I'm having a heck of a time
putting together an ICETOOL step.

The output is every record in dataset 1 that has a matching key in
dataset 2.



The 2 datasets have different LRECLs and the key is in different
positions.

   DS1:   LRECL=400   KEY=7 for a length of 13  (note: 7 is column
position, not offset)

   DS2:   LRECL=80 KEY=2 for a length of 13

OUTPUT is all records in DS1 that have a matching key in DS2.



I've looked at the SELECT and SPLICE examples in the DFSORT guide and
here is what I have but I'm guessing I'm way off base.

I'm getting records from both input datasets into the output where I
require only the records from DS1.

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

Re: DFSORT - ICETOOL Question

[George.William]

Thanks Barry!
I used to have this bookmarked but the bookmark I had no longer was
valid.
I've now got it re-bookmarked!

Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Schwarz, Barry A
Sent: Friday, May 21, 2010 11:33 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: DFSORT - ICETOOL Question

Page 9 of
http://www-947.ibm.com/systems/support/storage/software/sort/mvs/tricks/
pdf/sorttrck.pdf has a sample of how to do this.

__
CONFIDENTIALITY NOTICE: This email from the State of California is for the sole 
use of the intended recipient and may contain confidential and privileged 
information. Any unauthorized review or use, including disclosure or 
distribution, is prohibited. If you are not the intended recipient, please 
contact the sender and destroy all copies of this email.

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

Re: FTP Get Blocked by ISPF EDIT

[Al Cole]

In all of the FTP data processes that I create, I require that the users edits 
and maintains the data file in their application directories. 
When they have completed creating the file, the user or the application will 
move the file to an FTP server. By doing so, the user or application is stating 
that the file is complete and ready for processing.

The mainframe job will upload, backup, process and delete the file from the 
server.  

Alfred Cole
BJC HealthCare
mailstop 92-92-117
8374 Eager Road Suite 200
St Louis, MO 63144

(314) 362-7837
ahc5...@bjc.org



>>> "Patrick Lyon"  5/21/2010 1:18 PM >>>
On Fri, 21 May 2010 10:47:38 -0700, Charles Mills  
wrote:

>"Old data" is not a problem. Had he FTPed two minutes earlier he would have
>gotten "old" data. All data is "old" in that it may change at some point in
>the future. The "problem" is only if the user does a "preliminary" save --
>being cautious after having made half of his changes -- and you GET a
>version that was never intended to be integral.
>

I beg to differ.  Any data read prior to update would not be "old" data.  It 
is "current" data at that time.  Regardless of the validity of the data.

But once again, it's Friday.  :)

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

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

Re: What am I missing on XPLINK(OSCALL(N)) ?

[Charles Mills]

> If your assembler code expects the standard register conventions ...

My understanding of XPL(OSCALL(N)) is that is says "call the assembler
routines the old way." Am I missing something?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Dave Day
Sent: Friday, May 21, 2010 11:23 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What am I missing on XPLINK(OSCALL(N)) ?

SNIP  

I've got some C++ code. The C++ code calls several functions written in
assembler. This all works non-XPLINK. I compile it with XPL(OSCALL(N)). I
bind into a PDSE. I run it z/OS batch. The C++ code takes off and runs. I
can see that it survives several C++ method calls. The first call to one of
the assembler functions it falls on its face somewhere after leaving the C++
code and before returning. Storage has been overlaid badly enough that the
save area trace and so forth is pretty much junk. I have desk-checked the
assembler function - it's only 50 lines including lots of comments - and as
I said, it works non-XPLINK. It makes no calls although it does do a STORAGE
OBTAIN,LOC=24

SNIP

You may have already taken this into account, but the whole thing with
XPLINK is that it is a different linkage mechanism between modules.  If your
assembler code expects the standard register conventions, what piece of code
in the calling C++ would do that? 

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

Re: FTP Get Blocked by ISPF EDIT

[Ted MacNEIL]

>So how is MVS supposed to distinguish between an instance of someone who 
>shouldn't be editing the data or has no intention of saving vs. someone who is 
>editing critical changes that must be saved before the next remote GET should 
>be allowed

Can't do it.
Using EDIT as BROWSE is an educational issue.
Step 1: if the user shouldn't be reading/editing, block it with your ESM.
Step 2: teach your users to use BROWSE (or, gasp, VIEW) to browse and EDIT to 
edit.
(It's the old: "Doctor, it hurts when I do this" -- "Then STOP doing that")
-
Too busy driving to stop for gas!

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

Re: DFHSM Doc on when it resets the "dataset changed flag(bit)"

[Gibney, Dave]

Autobackup Y, we don't do full volumes with HSM. HSM is purely for user
convenient restores and does our migration. FDR does the full volume
plus incremental for DR purposes.

That's my answer isn't it. I bet (and reading between the lines) HSM
only resets the flag for BACKVOL. Autobackup is based on BCDS metadata
:)

But, if I let FDR reset the flag, HSM won't catch changed datasets.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of John H Kington
> Sent: Friday, May 21, 2010 11:12 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DFHSM Doc on when it resets the "dataset changed
> flag(bit)"
> 
> Dave,
> Are you using autobackup y on your storage groups or the incremental
> option on the backvol command(s)?
> Regards,
> John
> 513-723-7527
> john.king...@convergys.com
> 
> From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf
Of
> Gibney, Dave [gib...@wsu.edu]
> Sent: Friday, May 21, 2010 1:16 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: DFHSM Doc on when it resets the "dataset changed flag(bit)"
> 
> I can't find a definitive statement in the DFhsm books as to when and
> how this flag is reset when backing up. Or does it set it at all?
> 
> For historical (hysterical) reasons, we do both FDR and HSM backups.
> FDR
> for the hypothetical:) DR and HSM for user convenience.
> Awhile back, we made a markedly unsuccessful attempt to switch
> completely to FDR. We've lost to Systems people since and are unlikely
> to try again.
> 
> Anyway, FDR has a setting to not reset the flag in a mixed environment
> like this. I thought DFHSM would reset it but it appears that the flag
> is not being reset by anything and I'm getting an additional and
> unneeded back-up by each FDR run. HSM appears to be following the SMS
> definition for back-up frequency.
> 
> Ibmlink SIS didn't find anything, but crafting a proper search
argument
> for this is problematic. Data and changed and flag appear frequently
:)
> 
> Dave Gibney
> Information Technology Services
> Washington State University
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> NOTICE:  The information contained in this electronic mail
transmission
> is intended by Convergys Corporation for the use of the named
> individual or entity to which it is directed and may contain
> information that is privileged or otherwise confidential.  If you have
> received this electronic mail transmission in error, please delete it
> from your system without copying or forwarding it, and notify the
> sender of the error by reply email or by telephone (collect), so that
> the sender's address records can be corrected.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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