Re: Printing limits and userids

[Linda Mooney]

Hi Dave, 

  

I know that you have the LRS products and some JES2 printing.  What kind(s) of 
Jes2 printing (PSF, InfoPrint, line print) do you do?  VPS printers can have 
limits set.  In my shop there is a global limit set on print size in the VPS 
default member, then some printers have different limits (larger or smaller) 
coded within each printer member.  And some printers have multiple names and 
definitions, so that other options can easily be managed.  Printers with 
multiple names and VPS members all print to the same final print queue if they 
are destined for the same physical printer.  That last part is done with a 
second VPS stc.  Very easy to set up. 




JES2 printers can be limited to specific queue, line and or page limit, form, 
etc.  In my shop, different output classes get different handling.  There is a 
class for production line print on an impact printer.  A separate clas s for 
production laser print - we use PSF .  The are several output classes for 
programmer output.  No programmer output is printed until the programmer checks 
it and sends to a printable class.  At the end of the day, a JES offload picks 
up the programmer output, writes it to tape, deletes the output from JES2, and 
immediately reloads everything that was in  class M or T to JES2 in class H.  
Everything that was originally in class H is not reloaded, but moved to the 
online viewer.  We used to print a lot, but now most use the online viewer and 
print only selected pages from it.  


HTH, 



Linda 

- Original Message -




From: "Dave L - Eagan Hansen, MN"  
To: IBM-MAIN@bama.ua.edu 
Sent: Thursday, March 29, 2012 2:29:29 PM 
Subject: Printing limits and userids 

Group, 

  We have a lot of large reports in our MVS spool.  Any suggestions on limiting 
users from printing large reports by their userids, or a way to differentiate 
between valid print processing and potentially erroneous print processing by 
report name with JES2?  A 50,000 page report may be valid if coming from a 
production job but may well be in error if generated by a user/programmer.  
Somehow there would need to be a reference to valid users (userids), valid 
production jobs, valid printers, and number of pages.  The pages may not be 
correct because the APF information has not been converted. 

  I contacted the RACF group and it appears there is no option to limit 
printing by userid. 

  I contacted our print software vendor (VPS).  I have two choices: 
     - Dynamically change the print page limit by printer.  Not userid specific 
and you can print in "sections" which will still get your print printed and not 
exceed the limit of printable pages. 
     - Use Exit 22 where we can trap the userid and requeue the large report 
output if it meets specifications.  Then an appropriate operator command will 
need to be issued to JES to make SYSOUT available for printing again.  Sounds 
like big overhead.   

  So, any job can send output to the MVS spool.  Maybe I could dedicate a class 
or job form for the large reports, but I don't know the best way to do this in 
JES2.  From what I've seen you can just change the JES2 resources. and away 
goes the user/programmer's large report to the wrong printer. 
   

   Many thanks in advance,  Dave   


Dave Hansen 
Eagan Software Systems Branch 
651-406-1208 
dave.l.han...@usps.gov 

  

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

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

Re: Printing limits and userids

[Hansen, Dave L - Eagan, MN]

Group,

  We are running z/OS V1R12 and z/OS V1R13.  Currently we print to IP printers 
using VPS.  However JES2 also does 3270 print to high-speed laser printers.  
The request I was given is to limit print for both IP and 3270 printing.  It 
was a small brain-storm but this is what we came up with:

  Opt 1).  Convert all print to IP print.  Then use VPS exits to work a 
miracle.  Drawbacks?  The high-speed laser printers might not be as high speed.

  Opt 2).  New MVS spool only for this big stuff.  z/OS V1R13 supports a 
secondary JES2 spool.  For z/OS V1R12 I think I would need a new LPAR to get a 
new JES2 spool.  Drawbacks?  NJE would be used to send print from one spool to 
the other using RACF userid security.

  Opt 3).  z/OS V1R13 also can select jobs to be printed based on the amount of 
output to be printed in each job and direct the print jobs to appropriate 
printers.  Drawbacks?  Looks like you have to use IP PrintWay to do this and we 
don't have IP PrintWay.

  Some information came from the "z/OS Infoprint Server Introduction" 
(S544-5742-11) - What's new in z/OS V1R13. 

  Any comments? 


   Thanks,  Dave


Dave Hansen 
Eagan Software Systems Branch 
651-406-1208 
dave.l.han...@usps.gov 

 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Staller, Allan
Sent: Friday, March 30, 2012 8:13 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Printing limits and userids

I can't think of any way to do this natively with JES, VPS, or other exits.
The only thing I can think of is to write a batch program to invoke the SAPI 
interface and take the appropriate action (run on regular intervals).

Doc can be found in: z/OS V1R13.0 MVS Using the Subsystem Interface
SA22-7642-11

Located here:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2F290/CCON
TENTS?SHELF=iea2bkb3&DN=SA22-7642-11&DT=20110617222159

or 

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/DOWNLOAD/iea2f290.p
df?DN=SA22-7642-11&DT=20110617222159


HTH,


  We have a lot of large reports in our MVS spool.  Any suggestions on limiting 
users from printing large reports by their userids, or a way to differentiate 
between valid print processing and potentially erroneous print processing by 
report name with JES2?  A 50,000 page report may be valid if coming from a 
production job but may well be in error if generated by a user/programmer.  
Somehow there would need to be a reference to valid users (userids), valid 
production jobs, valid printers, and number of pages.  The pages may not be 
correct because the APF information has not been converted.


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

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

Re: Printing limits and userids

[Staller, Allan]

I can't think of any way to do this natively with JES, VPS, or other
exits.
The only thing I can think of is to write a batch program to invoke the
SAPI interface and take the appropriate action (run on regular
intervals).

Doc can be found in: z/OS V1R13.0 MVS Using the Subsystem Interface
SA22-7642-11

Located here:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2F290/CCON
TENTS?SHELF=iea2bkb3&DN=SA22-7642-11&DT=20110617222159

or 

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/DOWNLOAD/iea2f290.p
df?DN=SA22-7642-11&DT=20110617222159


HTH,


  We have a lot of large reports in our MVS spool.  Any suggestions on
limiting users from printing large reports by their userids, or a way to
differentiate between valid print processing and potentially erroneous
print processing by report name with JES2?  A 50,000 page report may be
valid if coming from a production job but may well be in error if
generated by a user/programmer.  Somehow there would need to be a
reference to valid users (userids), valid production jobs, valid
printers, and number of pages.  The pages may not be correct because the
APF information has not been converted.


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

Re: Printing limits and userids

[Mark Douglas (CITEC)]

1. Also Vps exit13 should support selective requeueing based on 'Word 3 (+12) 
Address of Dataset Attributes (VPSSDSAT)'.
2. You could always define separate queues for batch and user output pointing 
to the same destination. Then each queue can have tailored REQ* parms.
3. If you are patient, you can ask LRS to add this functionality to a future 
Vps release. They have been receptive to coding exit logic into simple 
parameters with the dataset add Exit 14 precedent. In fact LRS has been my most 
approachable vendor to date.

Cheers,
MARK DOUGLAS 
Senior IT Support Consultant
Mainframe
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Hansen, Dave L - Eagan, MN
Sent: Friday, 30 March 2012 7:29 AM
To: IBM-MAIN@bama.ua.edu
Subject: Printing limits and userids

Group,

  We have a lot of large reports in our MVS spool.  Any suggestions on limiting 
users from printing large reports by their userids, or a way to differentiate 
between valid print processing and potentially erroneous print processing by 
report name with JES2?  A 50,000 page report may be valid if coming from a 
production job but may well be in error if generated by a user/programmer.  
Somehow there would need to be a reference to valid users (userids), valid 
production jobs, valid printers, and number of pages.  The pages may not be 
correct because the APF information has not been converted.

  I contacted the RACF group and it appears there is no option to limit 
printing by userid.

  I contacted our print software vendor (VPS).  I have two choices:
 - Dynamically change the print page limit by printer.  Not userid specific 
and you can print in "sections" which will still get your print printed and not 
exceed the limit of printable pages.
 - Use Exit 22 where we can trap the userid and requeue the large report 
output if it meets specifications.  Then an appropriate operator command will 
need to be issued to JES to make SYSOUT available for printing again.  Sounds 
like big overhead.  

  So, any job can send output to the MVS spool.  Maybe I could dedicate a class 
or job form for the large reports, but I don't know the best way to do this in 
JES2.  From what I've seen you can just change the JES2 resources. and away 
goes the user/programmer's large report to the wrong printer.
   

   Many thanks in advance,  Dave  


Dave Hansen 
Eagan Software Systems Branch 
651-406-1208 
dave.l.han...@usps.gov 

 

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


* Disclaimer *

The contents of this electronic message and any attachments are intended only 
for the addressee and may contain privileged or confidential information. They 
may only be used for the purposes for which they were supplied. If you are not 
the addressee, you are notified that any transmission, distribution, 
downloading, printing or photocopying of the contents of this message or 
attachments is strictly prohibited. The privilege of confidentiality attached 
to this message and attachments is not waived, lost or destroyed by reason of 
mistaken delivery to you. If you receive this message in error please notify 
the sender by return e-mail or telephone.

Please note: the Department of Public Works carries out automatic software 
scanning, filtering and blocking of E-mails and attachments (including emails 
of a personal nature) for detection of viruses, malicious code, SPAM, 
executable programs or content it deems unacceptable. All reasonable 
precautions will be taken to respect the privacy of individuals in accordance 
with the Information Privacy Act 2009 (Qld). Personal information will only be 
used for official purposes, e.g. monitoring Departmental Personnel's compliance 
with Departmental Policies. Personal information will not be divulged or 
disclosed to others, unless authorised or required by Departmental Policy 
and/or law.

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

Printing limits and userids

[Hansen, Dave L - Eagan, MN]

Group,

  We have a lot of large reports in our MVS spool.  Any suggestions on limiting 
users from printing large reports by their userids, or a way to differentiate 
between valid print processing and potentially erroneous print processing by 
report name with JES2?  A 50,000 page report may be valid if coming from a 
production job but may well be in error if generated by a user/programmer.  
Somehow there would need to be a reference to valid users (userids), valid 
production jobs, valid printers, and number of pages.  The pages may not be 
correct because the APF information has not been converted.

  I contacted the RACF group and it appears there is no option to limit 
printing by userid.

  I contacted our print software vendor (VPS).  I have two choices:
 - Dynamically change the print page limit by printer.  Not userid specific 
and you can print in "sections" which will still get your print printed and not 
exceed the limit of printable pages.
 - Use Exit 22 where we can trap the userid and requeue the large report 
output if it meets specifications.  Then an appropriate operator command will 
need to be issued to JES to make SYSOUT available for printing again.  Sounds 
like big overhead.  

  So, any job can send output to the MVS spool.  Maybe I could dedicate a class 
or job form for the large reports, but I don't know the best way to do this in 
JES2.  From what I've seen you can just change the JES2 resources. and away 
goes the user/programmer's large report to the wrong printer.
   

   Many thanks in advance,  Dave  


Dave Hansen 
Eagan Software Systems Branch 
651-406-1208 
dave.l.han...@usps.gov 

 

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

Matching IP address with TSO userids

[Chris Mason]

All attracted to the Subject line

This was a question and single limited-scope response picked up in a Google 
Groups digest but *not* found in the archives.

-

Robert (and Taltyman)

> Is there an easy way ...

This depends on your definition of easy!

> ... of matching the IP addresses returned by an NETSTAT ALLCON ... with 
> actual users logged on to the system?

The most appropriate response here to the apparent requirement may be the one 
traditionally ascribed to the Irishman giving directions: "I wouldn't be 
starting from here, so I wouldn't!"

If what you want is a table with each row corresponding to each logged-on TSO 
user with a column for the userid and a column for the IP address corresponding 
to the TN3270 client at which that logged on user is sitting, you should start 
with the TSO user.

First you need to be presenting your commands to the z/OS system supporting the 
TSO users.

This is some flavour of the DISPLAY TS command. I don't have a system to hand 
but I'm sure you'll quickly discover how to get the output you need which is 
simply the list of your current TSO users.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2G1B1/4.10.39[1]

Now, by "hand" or by Clist - I grew up with NetView as the environment where I 
could enter commands and then work on the output returned - you need to take 
each userid and specify it in the following command:

DISPLAY NET,TSOUSER,ID=userid

Ideally the output is as shown in the following example I took from the z/OS 
Communications Server (CS) SNA Operations manual:



Displaying a TSO user ID when the SLU is a Telnet client:

d net,tsouser,id=user1

IST097I DISPLAY ACCEPTED
IST075I NAME = USER1, TYPE = TSO USERID
IST486I STATUS= ACTIV, DESIRED STATE= N/A
IST576I TSO TRACE = OFF
IST262I ACBNAME = TSO0001, STATUS = ACT/S
IST262I LUNAME = TCPM1011, STATUS = ACT/SY
IST1727I DNS NAME: VIC127.TCP.RALEIGH.IBM.COM
IST1669I IPADDR..PORT 9.67.113.83..1027
IST2203I CHARACTER SET 0065 CODE PAGE 0025
IST314I END



Why do I say ideally? The possible problem is that the IST1669I message may not 
be there. (Also the IST1727I message may not be there.[2])

First, you need to be sure that all VTAM systems through which the setup 
requests for initiating the SNA session between the TELNET server and TSO are 
happy to pass the Control Vector 64 (CV64). The start option which controls 
this behaviour is IPINFO and the default value, SENDALL, is least restrictive 
so probably (all) the IPINFO start option(s) is/are set correctly for you.

Next, until you reach z/OS V1R12, you need *not* to be using any session 
manager in relay mode. From V1R12 you need to make sure that whatever session 
manager you may be using has the necessary support to pass the CV64 from the 
primary LU logic to the secondary LU logic.

-

In case it is also of interest, you may be interested to check out the 
significance of the IKT122I (and IKT123I and IKT124I) messages in the CS SNA 
Messages manual:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1C6A0/3.41

-

Note that the greatest concentration of expertise regarding CS matters, both IP 
and SNA, is in the following list:

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

-

[1] I see you are using z/OS V1R6. I hope you'll excuse my using the V1R12 
library for reference. I don't think it's going to make any difference - except 
V1R12 is supported and I'm not sure V1R6 is!

[2] But, if that looks interesting, you'll need to include - apparently quite 
spuriously - a dummy HNGROUP:

HNGROUP DUMMY * ENDHNGROUP

in the PROFILE data set used by your TELNET server - another story I'll go into 
on request - assuming you don't have at least one already. The idea is to 
require the TELNET server to resolve the TELNET client IP address to a 
fully-qualified domain name.

-

Chris Mason

-

Robert AH Prins

Mon, 15 Aug 2011 18:14:21 +0100

Is there an easy way of matching the IP addresses returned by an NETSTAT
ALLCON, ie something like (addresses obscured)

MVS TCP/IP NETSTAT CS V1R6   TCPIP Name: TCPIP   16:04:52
User Id  Conn Local Socket   Foreign Socket State
---      -- -
TCPIP20D6 aaa.bbb.c.dd..23   abb.afg.baa.aab..dicda Establsh
TCPIP20E9 aaa.bbb.c.dd..23   abb.afg.baa.aab..dihbb Establsh
TCPIP20EE aaa.bbb.c.dd..23   abb.afg.baa.aab..dihfe Establsh
TCPIP21DE aaa.bbb.c.dd..23   fi.id.afi.ace..bgchi   Establsh
TCPIP2091 aaa.bbb.c.dd..23   eh.di.bch.ade..eidde   Establsh
TCPIP209D aaa.bbb.c.dd..23   eh.di.bch.ade..eifai   Establsh
TCPIP201D aaa.bbb.c.dd..23   aig.abh.ae.id..ebfae   Establsh

with actual users logged on to the system?

Thanks,

Robert
-- 
Robert AH Prins
robert(a)prino(d)org 

-

taltyman

Mon, 15 Aug 2011 13:39:53 -0700 (PDT)

D NET,I

Fw: Numeric TSO Userids

[Ted MacNEIL]

This was intended for the list
-
Too busy driving to stop for gas!

-Original Message-
From: "Ted MacNEIL" <[EMAIL PROTECTED]>

Date: Thu, 24 Jul 2008 21:44:20 
To: <[EMAIL PROTECTED]>
Subject: Re: Numeric TSO Userids


>I don't think RACF restricts you to 7-character userids.  We have a bunch of 
>8-character userids that work just fine in CICS.  But TSO won't
let them login -- get "IKJ56710I INVALID USERID".

That's because TSO is designed to only allow 7-character id's.

>I was also able to create an 8-digit userid and login to CICS.  When I try to 
>login to TSO with it I get "IKJ56710I INVALID USERID".
>So I'm convinced it's a TSO problem.

It's not a TSO problem, unless you consider that the design was set for 7 
characters.

Why are we complaining, now, about something that has been around for almost 40 
years?

-
Too busy driving to stop for gas!

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

Re: Numeric TSO Userids

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Mark Wilson
> 
> All,
> 
> From the research I have done I agree with Walt in that it¹s 
> a TSO restriction.
> 
> If you logon (Full screen mode) and enter a numeric Userid 
> you get the not valid message, press F1 and there is the 
> message from TSO.
> 
> Hence, my thinking I may be able to get at the field in a TSO 
> EXIT and bypass the numeric check.
> 
> The fact that ACF2 supports it means it can be done and from 
> what I am seeing there are no issues with MVS commands, INTRDR, etc.
> 
> Looks like I go back to the manuals to see if I can figure this out.

>From the z/OS 1.9 MVS JCL Reference manual, for the JOB statement:

= Begin paste ==
20.1.2 Name Field


Code a jobname on every JOB statement, as follows: 


Each jobname must be unique. 

The jobname must begin in column 3. 

The jobname is 1 through 8 alphanumeric or national ($, #, @) characters. If 
your system uses ANSI tapes, the jobname must contain only alphanumeric 
characters; it must not contain national ($, #, @) characters. 

The first character must be alphabetic or national ($, #, @). 
 End paste ==

Thus, it appears that jobnames beginning with a numeric userID would fail 
immediately.

-jc-

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

Re: Numeric TSO Userids

[Mark Wilson]

Kees,

I cannot name names as they are still here :).

I cannot change the numeric Users as the bussiness apps (none TSO) have it
hard coded to support only numeric users.

I have a work around which is two userids with password sync using RACF
RACLINK. But this means changing Multsess to prefix the logon to TSO.

Really looking for a way to support numeric TSO logon.

Mark



On 23/07/2008 08:00, "Vernooy, C.P. - SPLXM" <[EMAIL PROTECTED]> wrote:

> 
> 
> Gee, who in the first place decided to use numeric userids, possibly
> supported by ACF2, but not by the rest of MVS? Sounds like allowing
> Syncsort options and then return to DFSORT, or allow PDSFAST options and
> then return to IEBCOPY or...
> 
> If you did already prefix the userid with an Alpha character, can't you
> definitely change the userid to that prefixed value? It won't make any
> difference for the datasets, only the users have to get used to their
> 'new' userid, which they already know from their datasets?
> 
> Kees.
> 
> "Mark Wilson" <[EMAIL PROTECTED]> wrote in message
> news:<[EMAIL PROTECTED]>...
>> > Cross Posted to RACF-L and re posted to IBM Main
>> >
>> > Could anybody offer any ideas at all in this area?
>> >
>> > Regards
>> >
>> > Mark
>> > 
>> >
> 
> 
>> > ******
>> >
>> > Hi,
>> >
>> > I am in the middle of migrating a customer from ACF2 to RACF and have
>> > encountered a problem.
>> >
>> > ACF2 supports the use of fully numeric TSO Userids.
>> >
>> > The customer has an exit in place that forces all dataset allocations
> to be
>> > prefixed with a Alpha character, getting around the dataset issues.
>> >
>> > However, if I migrate them to RACF, TSO does NOT support a fully
> numeric
>> > Userid.
>> >
>> > I know this is not supported by IBM, but does anyone have any ideas
> (TSO
>> > exit?), that I can use to support fully numeric TSO Userids.
>> >
>> > The customer does not what to change the RACF Userids to start with an
> alpha
>> > character for business/application reasons.
>> >
>> > Any help gratefully received.
>> >
>> > Regards,
>> >
>> > Mark
>> >
>> > --
>> > For IBM-MAIN subscribe / signoff / archive access instructions,
>> > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
>> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
>> >
> **
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee
> only. If you are not the addressee, you are notified that no part
> of the e-mail or any attachment may be disclosed, copied or
> distributed, and that any other action related to this e-mail or
> attachment is strictly prohibited, and may be unlawful. If you have
> received this e-mail by error, please notify the sender immediately
> by return e-mail, and delete this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
> and/or its employees shall not be liable for the incorrect or
> incomplete transmission of this e-mail or any attachments, nor
> responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> Dutch Airlines) is registered in Amstelveen, The Netherlands, with
> registered number 33014286
> **
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 
> 
> 

 
___
Mark Wilson
 
Mobile: +44 (0) 7768 617006
Email:   [EMAIL PROTECTED]
 
Chairman GSE Large Systems Working Group.
Large Systems Web Site is:
http://lsx.gse.org.uk/
___



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

Re: Numeric TSO Userids

[Vernooy, C.P. - SPLXM]

Gee, who in the first place decided to use numeric userids, possibly
supported by ACF2, but not by the rest of MVS? Sounds like allowing
Syncsort options and then return to DFSORT, or allow PDSFAST options and
then return to IEBCOPY or...

If you did already prefix the userid with an Alpha character, can't you
definitely change the userid to that prefixed value? It won't make any
difference for the datasets, only the users have to get used to their
'new' userid, which they already know from their datasets?

Kees.

"Mark Wilson" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Cross Posted to RACF-L and re posted to IBM Main
> 
> Could anybody offer any ideas at all in this area?
> 
> Regards
> 
> Mark
>  
>


> **
> 
> Hi,
> 
> I am in the middle of migrating a customer from ACF2 to RACF and have
> encountered a problem.
> 
> ACF2 supports the use of fully numeric TSO Userids.
> 
> The customer has an exit in place that forces all dataset allocations
to be
> prefixed with a Alpha character, getting around the dataset issues.
> 
> However, if I migrate them to RACF, TSO does NOT support a fully
numeric
> Userid.
> 
> I know this is not supported by IBM, but does anyone have any ideas
(TSO
> exit?), that I can use to support fully numeric TSO Userids.
> 
> The customer does not what to change the RACF Userids to start with an
alpha
> character for business/application reasons.
> 
> Any help gratefully received.
> 
> Regards,
> 
> Mark
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
**
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

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

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

Re: Numeric TSO Userids

[Mark Wilson]

All,

>From the research I have done I agree with Walt in that it¹s a TSO
restriction.

If you logon (Full screen mode) and enter a numeric Userid you get the not
valid message, press F1 and there is the message from TSO.

Hence, my thinking I may be able to get at the field in a TSO EXIT and
bypass the numeric check.

The fact that ACF2 supports it means it can be done and from what I am
seeing there are no issues with MVS commands, INTRDR, etc.

Looks like I go back to the manuals to see if I can figure this out.

Mark



On 23/07/2008 03:00, "Walt Farrell" <[EMAIL PROTECTED]> wrote:

> On 7/22/2008 6:15 PM, Barry Schrager wrote:
>> > I agree -- HASP has nothing to do with this.  The 7 character limit was
>> > imposed because submitted jobs had the Userid as the first 7 characters
>> > and had to attach another character/digit to make the submitted jobname
>> > unique.
>> >
>> > It never occurred to us that you might have 7 digit Userids when we
>> > created ACF2.  That, it works, is a surprise to me.  I guess that by
>> > bypassing UADS, nobody checks -- but RACF obviously does.
>> >
> Interesting, Barry.  RACF doesn't check, and fully supports numeric user
> IDs.  It has to be a TSO/E restriction, and I'm pretty sure that the
> standard TSO/E logon command parsing (and full-screen validation) will
> reject a numeric user ID, so I always figured it was done with logon
> exits and/or replacement of the logon command when another security
> product does allow it.
> 
> --
> Walt Farrell, CISSP
> IBM STSM, z/OS Security Design
> 
> 
> 
> 

 
___
Mark Wilson
 
Mobile: +44 (0) 7768 617006
Email:   [EMAIL PROTECTED]
 
Chairman GSE Large Systems Working Group.
Large Systems Web Site is:
http://lsx.gse.org.uk/
___



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

Re: Numeric TSO Userids

[Thompson, Steve]

-Original Message-
From: RACF Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of
Thompson, Steve
Sent: Tuesday, July 22, 2008 4:56 PM
To: [EMAIL PROTECTED]
Subject: Re: Numeric TSO Userids



If TSS could do it, then why couldn't it be done in a RACF environment?
ISPF shouldn't choke on this, after all, as the original poster said,
they already prefix the "TSOID" with a letter, which would give a max
HLQ of 8 characters.


Sorry, I had Top Secret running around in my head this afternoon. I
meant ACF2 as the original poster was saying. Long day.

Regards,
Steve Thompson

-- All opinions expressed by me are my own and may not necessarily
reflect those of my employer. --

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

Re: Numeric TSO Userids

[Thompson, Steve]

-Original Message-
From: RACF Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of
Doc Farmer
Sent: Tuesday, July 22, 2008 2:14 PM
To: [EMAIL PROTECTED]
Subject: Re: FW: Numeric TSO Userids

As Bender of Futurama might say, "We're Boned!"

Sorry, the Wonderful Wizards of HASP decided that a TSO User ID in RACF
must be only 7 characters in length and must start with an alpha
character only.
I think you're gonna have some fun renaming all those old IDs (and all
those old Datasets) to the new format.  I doubt you'd have an exit that
could work that wouldn't also screw up your other operations, so get
ready to do some bulk renaming.


If TSS could do it, then why couldn't it be done in a RACF environment?
ISPF shouldn't choke on this, after all, as the original poster said,
they already prefix the "TSOID" with a letter, which would give a max
HLQ of 8 characters.

The Submit Exit and INTRDR may need a little tweaking.

I'd think that the thing to do is bring up a NON-TSS system with RACF
(standalone). Your first problem is going to be the TSO PREFIX
PROFILE(nn) because it is going to give you this: IKJ56710I INVALID
USERID, 1234567

Once you get that to work, you can set your prefix to your TSS ID (all
numbers) and see what falls out next.

What one might do, if TopSecret is installed with SMPE is look at the
++USERMODS and what they apply to. That will give you some ideas of what
you will need to handle. If it is an IEBCOPY install, look to see what
it requires to be installed that happens to have "IBM" owned program
(CSECT/MODULE) names.

You just might be able to pull off the same things TSS does to allow
numeric TSO IDs. Or you may be able to prove to your management that
this will require a migration of TSO IDs, or stay on TSS (probably
justifying the license/maint fees for TSS to CA).

Regards,
Steve Thompson

-- All opinions expressed by me are my own and may not necessarily
reflect those of my employer. --

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

Re: Numeric TSO Userids

[Itschak Mugzach]

Saw your main in RACF-L as well. The answer is TSO logon exit. Have the user
be aware to his numeric id, not more then six chars and prefix a character
or assign another UID. I have a similar problem at a customer here who
converted from VSE to MVS. Not a big problem., but I would keep a sync.
Between the userid and the numeric value in RACF. Perhaps an other class
that can hold a numeric value and a field that holds the userid. 

Itschak  


| Itschak Mugzach | Director | SecuriTeam Software |
| Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: Itschak
Mugzach | Web: www.Securiteam.co.il  | 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Mark Wilson
Sent: Tuesday, July 22, 2008 9:03 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: FW: Numeric TSO Userids

Cross Posted to RACF-L and re posted to IBM Main

Could anybody offer any ideas at all in this area?

Regards

Mark
 

**

Hi,

I am in the middle of migrating a customer from ACF2 to RACF and have
encountered a problem.

ACF2 supports the use of fully numeric TSO Userids.

The customer has an exit in place that forces all dataset allocations to be
prefixed with a Alpha character, getting around the dataset issues.

However, if I migrate them to RACF, TSO does NOT support a fully numeric
Userid.

I know this is not supported by IBM, but does anyone have any ideas (TSO
exit?), that I can use to support fully numeric TSO Userids.

The customer does not what to change the RACF Userids to start with an alpha
character for business/application reasons.

Any help gratefully received.

Regards,

Mark

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


__ NOD32 3280 (20080718) Information __

This message was checked by NOD32 antivirus system.
http://www.eset.com

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

Re: Numeric TSO Userids

[Itschak Mugzach]

 


| Itschak Mugzach | Director | SecuriTeam Software |
| Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: Itschak
Mugzach | Web: www.Securiteam.co.il  | 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Mark Wilson
Sent: Tuesday, July 22, 2008 9:03 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: FW: Numeric TSO Userids

Cross Posted to RACF-L and re posted to IBM Main

Could anybody offer any ideas at all in this area?

Regards

Mark
 

**

Hi,

I am in the middle of migrating a customer from ACF2 to RACF and have
encountered a problem.

ACF2 supports the use of fully numeric TSO Userids.

The customer has an exit in place that forces all dataset allocations to be
prefixed with a Alpha character, getting around the dataset issues.

However, if I migrate them to RACF, TSO does NOT support a fully numeric
Userid.

I know this is not supported by IBM, but does anyone have any ideas (TSO
exit?), that I can use to support fully numeric TSO Userids.

The customer does not what to change the RACF Userids to start with an alpha
character for business/application reasons.

Any help gratefully received.

Regards,

Mark

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


__ NOD32 3280 (20080718) Information __

This message was checked by NOD32 antivirus system.
http://www.eset.com

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

FW: Numeric TSO Userids

[Mark Wilson]

Cross Posted to RACF-L and re posted to IBM Main

Could anybody offer any ideas at all in this area?

Regards

Mark
 

**

Hi,

I am in the middle of migrating a customer from ACF2 to RACF and have
encountered a problem.

ACF2 supports the use of fully numeric TSO Userids.

The customer has an exit in place that forces all dataset allocations to be
prefixed with a Alpha character, getting around the dataset issues.

However, if I migrate them to RACF, TSO does NOT support a fully numeric
Userid.

I know this is not supported by IBM, but does anyone have any ideas (TSO
exit?), that I can use to support fully numeric TSO Userids.

The customer does not what to change the RACF Userids to start with an alpha
character for business/application reasons.

Any help gratefully received.

Regards,

Mark

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

Re: Numeric TSO Userids

[Gerhard Postpischil]

Mark Wilson wrote:

However, if I migrate them to RACF, TSO does NOT support a fully numeric
Userid.


The closest you could come is to maintain an all-numeric logon 
in a pre-logon exit (examples on the CBT), and convert that to 
an id acceptable by TSO and RACF internally. If the clients run 
special software without direct TSO use, this could maintain 
transparency for them.


(There is of course the alternative of intercepting all terminal 
I/O, identifying the user ids, and changing them, but I wouldn't 
seriously recommend that)


A long time ago we had numeric account numbers, and (for 
billing) decided to use them as part of data set names. We 
translated A-I to 1-9, and 0 to Z. That worked quite well, but 
didn't suffer from the TSO userid restrictions.



Gerhard Postpischil
Bradford, VT

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

Numeric TSO Userids

[Mark Wilson]

Hi,

I am in the middle of migrating a customer from ACF2 to RACF and have
encountered a problem.

ACF2 supports the use of fully numeric TSO Userids.

The customer has an exit in place that forces all dataset allocations to be
prefixed with a Alpha character, getting around the dataset issues.

However, if I migrate them to RACF, TSO does NOT support a fully numeric
Userid.

I know this is not supported by IBM, but does anyone have any ideas (TSO
exit?), that I can use to support fully numeric TSO Userids.

The customer does not what to change the RACF Userids to start with an alpha
character for business/application reasons.

Any help gratefully received.

Regards,

Mark


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

Re: z/OS 1.9 - STC userIDs - RACF OMVS segments

[Hal Merritt]

FYI a recent audit challenged the use of UID 0. The upshot was that UID
0 be allowed only with a clearly stated vendor requirement to include
why the mission could not be accomplished with SU as needed. Even then,
management approval was required. 

Please, no debate over questionable audit findings. Even with the added
protection of z/os security, UID zero is a significant risk. (Hold on to
your hat, but the auditor was able to describe a very plausible scenario
with an impressive grasp of the technical details.) 'Nuff said.   

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Chase, John
Sent: Thursday, May 29, 2008 9:10 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: z/OS 1.9 - STC userIDs - RACF OMVS segments

Hi, All,

We just IPLed z/OS 1.9 in the "sandbox", and among the "new stuff" we
noticed was an ICH408I message for the TMON userID not having READ
access to BPX.SUPERUSER.  After "fixing" that, I issued a LISTUSER
tmonID OMVS and discovered that it doesn't have an OMVS segment (its
default GROUP _does_ have one with a GID).

With z/OS becoming ever more tightly integrated with the UNIX side of
things, might it be wise to create OMVS segments for all STC userIDs
now?  

Corollary question:  Are there any UNIX-y things more-or-less "commonly
used" in z/OS that WILL NOT RUN without UID = 0?

BTW, ISPF option 3.17 looks to be "really handy".  Thanks, IBM.

TIA,

-jc-

 

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

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

z/OS 1.9 - STC userIDs - RACF OMVS segments

[Chase, John]

Hi, All,

We just IPLed z/OS 1.9 in the "sandbox", and among the "new stuff" we
noticed was an ICH408I message for the TMON userID not having READ
access to BPX.SUPERUSER.  After "fixing" that, I issued a LISTUSER
tmonID OMVS and discovered that it doesn't have an OMVS segment (its
default GROUP _does_ have one with a GID).

With z/OS becoming ever more tightly integrated with the UNIX side of
things, might it be wise to create OMVS segments for all STC userIDs
now?  

Corollary question:  Are there any UNIX-y things more-or-less "commonly
used" in z/OS that WILL NOT RUN without UID = 0?

BTW, ISPF option 3.17 looks to be "really handy".  Thanks, IBM.

TIA,

-jc-

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

RACF, Cloning Userids & ADCD

[Terry Sambrooks]

Hi,

On the general question of is there a sure-fire way of cloning a userid
within RACF, I cannot provide an answer but am able to offer insight I think
based on experience with the ADCD and a smattering of knowledge gained in
such an environment.

Remember that Userids in RACF belong to Groups and if access authorities to
other resources such as ACCTNUM, TSOPROC, JCL, OPE, Data sets etc., are
granted at the group level, then any new Userid added to that group
automatically picks up the same access authorities.

Unfortunately the Userids IBM provided with the ADCD system were granted
access to resources at the Userid rather Group level. (Check the Access List
for ACCTNUM/ACCT# and a list of Userids prefixed by ADCD will be shown.)
This inhibits simple cloning, whereas Group access aids it.

One lesson which was given to me by a colleague was to switch from using the
ISPF/RACF panels and revert to raw ISPF commands, held in a PDS member and
executed via batch TSO. This provides both a visible record of what has been
done, and the capability to reproduce the same if required.

Kind regards - Terry 

Terry Sambrooks
Director
KMS-IT Limited
228 Abbeydale Road South
Dore, Sheffield, S17 3LA, UK

Tel: +44 (0)114 262 0933
WEB: www.legac-e.co.uk

Company Reg: 3767263 at the above address

All outgoing E-mail is scanned, but it remains the recipient's
responsibility to ensure their system is protected from spy-ware, trojans,
viruses, and worms.  

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

pre-validating RACF userids and passwords in application - final status

[McKown, John]

Just to recap what I'm doing. I'm writing a Java application which runs
basically where ever Java can run. My target is for the desktop
environment (Windows, Linux, Mac). Part of the functionality is to do
ftp transfer. This is done by filling in the host, port number, userid,
and password on a panel. All of the fields with the exception of the
password are saved in a file and reloaded when the user reinvokes the
application. I will grant that this, in itself, could be considered poor
security, but that's they way it goes. Since the user may fill out this
panel some time before using the ftp function, I have included a
"Validate" button on the panel. All this does is attempt to connect to
an ftp server on the host, on the given port, using the given userid and
password. I give this oppertunity so that an ftp does not fail later
when the user actually tries to do the ftp function.

What I am actually doing, for learning purposes, is reimplementing IBM's
Softcopy Librarian application in 100% pure Java. IBM, for whatever
reason, has a mixture of Java and Windows programs to implement their
version. I cannot get it to run under Linux. I want it to run under
Linux, so I'm working on doing so. The panel containing the host, port,
userid, and password are part of IBM's design that I am more-or-less
replicating. The only enhancement is that I allow the user to validate
that they did not make a mistake here, rather than waiting until
actually attempting an ftp and having it fail for some reason. The
"validate" feedback is fairly simple of "Validate succeeded", "Validate
Failed. Unknown Host", "Validate Failed. Connection Refused.", or
"Validate failed.". This last is what happens when a person puts in a
bad userid or password. But that is all that I say. I don't regard this,
as one person averred, as a "hacking tool" because a person can do the
same thing from a simple ftp command line. It's not like I'm giving
anybody any information that they couldn't get otherwise using a simple
ftp client.

Thanks for your thoughts. The design is how etched in code. Which is
sometimes harder to get changed than rock! .

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

Re: pre-validating RACF userids and passwords in application.

[tony babonas]

But why solve the problems?  "Pre-validation" in this
sense could be renamed "let's try a few things to see
if we're close to guessing the password"  We currently
have this issue in our shop.  Us security types look at
it as "working as designed."  

Three strikes and you're out exists for a reason.  In
baseball you don't get pretend swings to determine if a
pitch is in the strike zone (apologies to non-US, non
Caribbean, non Japan, non Taiwan colleagues).

The app you are suggesting appears to be a hacking tool
in disguise.  (looks like a duck, walks like a duck,
quacks like a duck..)  

-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Crow
Sent: Thursday, July 12, 2007 6:30 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: pre-validating RACF userids and passwords
in application.

>-Original Message-
>From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On
Behalf >Of Kenneth E Tomiak
>Sent: 12 July 2007 00:07
>To: IBM-MAIN@BAMA.UA.EDU
>Subject: Re: pre-validating RACF userids and passwords
in application.

>>
>>
>>What I may do is to have a button like "Validate host
/ userid / 
>>password" so that the user can click that and attempt
to connect to
the
>>host using the given userid and password. If the
logon fails, I'll 
>>report that to the user. If the user doesn't want to
valid at that
time,
>>then it is his problem if the ftp fails later on.
That's what I'm
trying
>>to avoid.
>>
>>--
>
>If that validation fails it still counts as a strike
against the number
of >invalid 
>attempts. An easy way to get the userid revoked. You
know how impatient

>clickers are, they can click quicker than your
application can respond.
>

If the application is used to ftp several datasets with
a fat finger-ed password then you could use up all your
strikes in one go.

Any one submitted a job with several steps each
(N)FTP-ing a dataset and forgot the global change of
password. BTDTGTS.

The validate user/password button could save a lot of
problems.

Brian

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

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

Re: SPAM: Re: pre-validating RACF userids and passwords in application.

[Rick Fochtman]

---
In terms of validation, I was more thinking along the lines of "I know 
that RACF ids can be a maximum of 8 characters, and are composed of the 
characters A-Z,@#$,0-9. So I'll check that the id doesn't contain 
anything else." I don't consider this a security problem, per se, but a 
way to "help" somebody (like me) who may have "fat fingered" something.


Why bother? Let RACF do its job and don't try to "make things easier". 
True, you could do this with a couple of moves and a TRT, but RACF will 
be much more comprehensive, expecially in the light of whatever other 
rules might be in place under RACF.


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

Re: pre-validating RACF userids and passwords in application.

[Brian Crow]

>-Original Message-
>From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf >Of Kenneth E Tomiak
>Sent: 12 July 2007 00:07
>To: IBM-MAIN@BAMA.UA.EDU
>Subject: Re: pre-validating RACF userids and passwords in application.

>>
>>
>>What I may do is to have a button like "Validate host / userid /
>>password" so that the user can click that and attempt to connect to
the
>>host using the given userid and password. If the logon fails, I'll
>>report that to the user. If the user doesn't want to valid at that
time,
>>then it is his problem if the ftp fails later on. That's what I'm
trying
>>to avoid.
>>
>>--
>
>If that validation fails it still counts as a strike against the number
of >invalid 
>attempts. An easy way to get the userid revoked. You know how impatient

>clickers are, they can click quicker than your application can respond.
>

If the application is used to ftp several datasets with a fat finger-ed
password then you could use up all your strikes in one go.

Any one submitted a job with several steps each (N)FTP-ing a dataset and
forgot the global change of password. BTDTGTS.

The validate user/password button could save a lot of problems.

Brian

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

Re: pre-validating RACF userids and passwords in application.

[Walt Farrell]

On 7/11/2007 7:21 PM, Paul Gilmartin wrote:

Here, there seems to be some shortsightedness in the RACF design:

o If RACF is configured in the ASIS mode, all upstream facilities
  which accept passwords and make SAF calls to validate them must
  treat the passwords ASIS.


Yes.



o If RACF is configured in the CAPS mode, RACF should perform the
  folding; else it becomes the burden of every upstream facility
  to replicate the RACF option (or query RACF or RACF's PARMLIB
  entry) to determine whether to fold.  Better for RACF to
  perform the folding if necessary and all upstream facilities to
  pass passwords ASIS to the SAF interface.


I agree.  However, that design occurred over 30 years ago, and we would 
not change it now.  Most applications that call RACF are older ones that 
need to change anyway to accomodate mixed-case passwords.


If the administrator has configured RACF for mixed-case support, then 
RACF will handle upper-casing if needed for a particular user.




The ugly scenario occurs when a site which has been operating in
FOLD mode for decades chooses, motivated by an auditor's evaluation,
to convert to ASIS mode.  Then, all upstream folding utilities
must be rewritten and users must learn to lean on the SHIFT key
until they change their passwords to adapt.


Not true.  The applications simply need to stop folding when they detect 
mixed-case enablement.  If a user still has an upper-case password, and 
the application presents it without folding, RACF will upper-case it 
when configured for mixed-case.




The same applies to userids.  I believe there is no support for
mixed case userids, but RACF should, as a courtesy, fold them
also to avoid replication of code upstream and to allow for
mixed case userids in some future era.


Good suggestion, though I don't know of any plans to allow mixed-case 
IDs.  That affects a lot more than just the logon interface.


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

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

Re: pre-validating RACF userids and passwords in application.

[Paul Gilmartin]

On Wed, 11 Jul 2007 16:37:57 -0400, Thompson, Steve wrote:
>
>I know my userid and password. However, who (or what) converts it to
>upper case in a z/OS environment? An I/O buffer trace between my
>"terminal" and the host shows that they are all sent in lower case. But
>my system is not using the new RACF function/feature (that accepts mixed
>case). So who does the conversion?
>
>We know that it has to be done (fold to upper), because we have a
>product that has a SAF interface. If you have its interface option set
>to "ASIS" and then you do not give your userid in upper case to it, your
>login will fail. Same is true of the password.
>
>So the mindset of auditors and security persons who do not know the
>behind the scenes tech issues is just so much noise (my opinion).
>
Here, there seems to be some shortsightedness in the RACF design:

o If RACF is configured in the ASIS mode, all upstream facilities
  which accept passwords and make SAF calls to validate them must
  treat the passwords ASIS.

o If RACF is configured in the CAPS mode, RACF should perform the
  folding; else it becomes the burden of every upstream facility
  to replicate the RACF option (or query RACF or RACF's PARMLIB
  entry) to determine whether to fold.  Better for RACF to
  perform the folding if necessary and all upstream facilities to
  pass passwords ASIS to the SAF interface.

The ugly scenario occurs when a site which has been operating in
FOLD mode for decades chooses, motivated by an auditor's evaluation,
to convert to ASIS mode.  Then, all upstream folding utilities
must be rewritten and users must learn to lean on the SHIFT key
until they change their passwords to adapt.

The same applies to userids.  I believe there is no support for
mixed case userids, but RACF should, as a courtesy, fold them
also to avoid replication of code upstream and to allow for
mixed case userids in some future era.

-- gil

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

Re: pre-validating RACF userids and passwords in application.

[Kenneth E Tomiak]

>
>
>What I may do is to have a button like "Validate host / userid /
>password" so that the user can click that and attempt to connect to the
>host using the given userid and password. If the logon fails, I'll
>report that to the user. If the user doesn't want to valid at that time,
>then it is his problem if the ftp fails later on. That's what I'm trying
>to avoid.
>
>--

If that validation fails it still counts as a strike against the number of 
invalid 
attempts. An easy way to get the userid revoked. You know how impatient 
clickers are, they can click quicker than your application can respond.

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

Re: pre-validating RACF userids and passwords in application.

[Dave Kopischke]

On Wed, 11 Jul 2007 15:55:26 -0500, McKown, John wrote:
>
>In terms of validation, I was more thinking along the lines of "I know
>that RACF ids can be a maximum of 8 characters, and are composed of the
>characters A-Z,@#$,0-9. So I'll check that the id doesn't contain
>anything else." I don't consider this a security problem, per se, but a
>way to "help" somebody (like me) who may have "fat fingered" something.


When I fat-finger a user ID or password, it's because I hit a key next to the 
one I meant to strike. In most cases that will be just another letter or 
number. 
Your edits won't help my foibles. This kind of sounds like a solution looking 
for 
a problem. I think I'd leave it alone too.

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

Re: pre-validating RACF userids and passwords in application.

[Aaron Walker]

I think I would agree with those who are saying "Don't mess with it", not only 
because it might help the cracker, but also you may be eliding your own 
security policy.  You (hopefully) put a lot of thought into your RACF policy, 
so 
let RACF do it's job.  If people get bit/revoked because they fuzzy fingered it 
with a TSO session, and you have no problem with that, then I think your 
new "proxy" should retain the same severity of requirements.

Aaron

>
>In terms of validation, I was more thinking along the lines of "I know
>that RACF ids can be a maximum of 8 characters, and are composed of the
>characters A-Z,@#$,0-9. So I'll check that the id doesn't contain
>anything else." I don't consider this a security problem, per se, but a
>way to "help" somebody (like me) who may have "fat fingered" something.
>Otherwise, it will not be detected unless/until the person attempts an
>ftp (if they even do that).
>
>So far, the consensus of opinion is to allow the far end to even do
>syntax verification. Sounds good to me.
>
>What I may do is to have a button like "Validate host / userid /
>password" so that the user can click that and attempt to connect to the
>host using the given userid and password. If the logon fails, I'll
>report that to the user. If the user doesn't want to valid at that time,
>then it is his problem if the ftp fails later on. That's what I'm trying
>to avoid.
>
>--
>John McKown
>Senior Systems Programmer
>HealthMarkets
>Keeping the Promise of Affordable Coverage
>Administrative Services Group
>Information Technology
>

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

Re: pre-validating RACF userids and passwords in application.

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Lyon
> Sent: Wednesday, July 11, 2007 3:25 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: pre-validating RACF userids and passwords in application.
> 
> 
> On Wed, 11 Jul 2007 15:00:04 -0500, McKown, John 
> <[EMAIL PROTECTED]> wrote:
> 



> The mindset from a security person or an auditor would be 
> "helping" someone 
> figure out userid and password naming conventions only open 
> up possible 
> security breaches.
> 
> One would think that if someone were to attempt to access any 
> system on 
> any platform, that their userid and password should already be known.
> 
> This is just my opinion of course.
> 
> Pat L.
> 

In terms of validation, I was more thinking along the lines of "I know
that RACF ids can be a maximum of 8 characters, and are composed of the
characters A-Z,@#$,0-9. So I'll check that the id doesn't contain
anything else." I don't consider this a security problem, per se, but a
way to "help" somebody (like me) who may have "fat fingered" something.
Otherwise, it will not be detected unless/until the person attempts an
ftp (if they even do that).

So far, the consensus of opinion is to allow the far end to even do
syntax verification. Sounds good to me.

What I may do is to have a button like "Validate host / userid /
password" so that the user can click that and attempt to connect to the
host using the given userid and password. If the logon fails, I'll
report that to the user. If the user doesn't want to valid at that time,
then it is his problem if the ftp fails later on. That's what I'm trying
to avoid.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

Re: pre-validating RACF userids and passwords in application.

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Patrick Lyon
Sent: Wednesday, July 11, 2007 3:25 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: pre-validating RACF userids and passwords in application.

On Wed, 11 Jul 2007 15:00:04 -0500, McKown, John
<[EMAIL PROTECTED]> wrote:

>Should I "help" the user by double
>checking for possible bad userids (too long, bad characters), assuming 
>that the userid criteria in RACF is unlikely to ever change? Or should 
>I just pass along whatever the user types in without any validation so 
>that the program does not need to worry about any possible future RACF 
>enhancements?
>
>--
>John McKown

The mindset from a security person or an auditor would be "helping"
someone figure out userid and password naming conventions only open up
possible security breaches.

One would think that if someone were to attempt to access any system on
any platform, that their userid and password should already be known.


I know my userid and password. However, who (or what) converts it to
upper case in a z/OS environment? An I/O buffer trace between my
"terminal" and the host shows that they are all sent in lower case. But
my system is not using the new RACF function/feature (that accepts mixed
case). So who does the conversion?

We know that it has to be done (fold to upper), because we have a
product that has a SAF interface. If you have its interface option set
to "ASIS" and then you do not give your userid in upper case to it, your
login will fail. Same is true of the password. 

So the mindset of auditors and security persons who do not know the
behind the scenes tech issues is just so much noise (my opinion).

Regards,
Steve Thompson

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

Re: pre-validating RACF userids and passwords in application.

[Patrick Lyon]

On Wed, 11 Jul 2007 15:00:04 -0500, McKown, John 
<[EMAIL PROTECTED]> wrote:

>Should I "help" the user by double
>checking for possible bad userids (too long, bad characters), assuming
>that the userid criteria in RACF is unlikely to ever change? Or should I
>just pass along whatever the user types in without any validation so
>that the program does not need to worry about any possible future RACF
>enhancements?
>
>--
>John McKown

The mindset from a security person or an auditor would be "helping" someone 
figure out userid and password naming conventions only open up possible 
security breaches.

One would think that if someone were to attempt to access any system on 
any platform, that their userid and password should already be known.

This is just my opinion of course.

Pat L.

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

Re: pre-validating RACF userids and passwords in application.

[Paul Gilmartin]

On Wed, 11 Jul 2007 15:00:04 -0500, McKown, John <[EMAIL PROTECTED]> wrote:

>I'm working on a program, in Java, as a learning process. One feature
>that it will have is the ability to do ftp transfers. One of the
>parameters that is set is whether the ftp target is z/OS (targetting
>either legacy datasets or UNIX files), UNIX-like, or Windows-like. If
>the ftp target is z/OS, should I bother doing some
>validation/preprocessing of the userid and password? In particular,
>should I upcase the userid and check it for validity? The same for the
>password? I'm thinking "no" for the password due to the recent updating
>of RACF to accept lower case passwords as well as very long password
>phrases (or whatever they're calling them now).
>
>But the userid remains a question. Should I "help" the user by double
>checking for possible bad userids (too long, bad characters), assuming
>that the userid criteria in RACF is unlikely to ever change? Or should I
>just pass along whatever the user types in without any validation so
>that the program does not need to worry about any possible future RACF
>enhancements?
>
No.

As you have noted, it stifles innovation.

Possible misunderstanding by the implementor of the rules
leads to undue restrictions.

By a crude experiment, on some hosts I can't do "quote SYST" to
determine the remote system type until after a successful login.

-- gil

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

pre-validating RACF userids and passwords in application.

[McKown, John]

I'm working on a program, in Java, as a learning process. One feature
that it will have is the ability to do ftp transfers. One of the
parameters that is set is whether the ftp target is z/OS (targetting
either legacy datasets or UNIX files), UNIX-like, or Windows-like. If
the ftp target is z/OS, should I bother doing some
validation/preprocessing of the userid and password? In particular,
should I upcase the userid and check it for validity? The same for the
password? I'm thinking "no" for the password due to the recent updating
of RACF to accept lower case passwords as well as very long password
phrases (or whatever they're calling them now). 

But the userid remains a question. Should I "help" the user by double
checking for possible bad userids (too long, bad characters), assuming
that the userid criteria in RACF is unlikely to ever change? Or should I
just pass along whatever the user types in without any validation so
that the program does not need to worry about any possible future RACF
enhancements?

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

Re: Mixed case userids in z/OS & RACF

[Walt Farrell]

On 8/8/2006 5:19 PM, Steve Myers wrote:

Do z/OS and RACF support mixed case userids.


RACF command processors do not support the creation of mixed-case user 
IDs.  Technically you could create them using the lower level interface 
ICHEINTY.  However, it's unlikely that you'd get all the data put into 
the profile correctly, and for any future administration you would have 
do it yourself, again using ICHEINTY.




If the answer is No, then who is responsible for folding the userid to 
upper case?  RACF?  The RACROUTE caller?


The RACROUTE issuer.  Which gives you another problem, because even if 
you got the mixed-case ID created the applications would upper-case the 
ID and then RACF would not find it.


Walt Farrell, CISSP
z/OS Security Design, IBM

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Howard Brazee]

On 10-Jun-2005, [EMAIL PROTECTED] (Bruce Black) wrote:

> Intercourse, PA is very close to Blue Ball, PA.
> In the Cayman Islands, they have a town named Hell (because of the
> strange, hellish rock formations there).  Their principle industry is
> the post office/gift shop, where you can mail post cards postmarked Hell.

The crater on the moon is named after a monk named Hell.   Some Japanese cities
starting with "Fu" can be read very close to what you might fear.

When our database is international, we have to consider foreign words.   Same
thing for passwords.   I worked on a Vax one time where they had an English
language database that they checked passwords against.   A friend was French, so
she had no trouble getting around it.

I wouldn't be surprised at all if some people or addresses have names which are
spelled the same way as foreign language obscenities.   Plus, some people
putting in fake names or addresses will enter "funny" phrases.   (the law firm
of "Dewey, Cheatm, and Howe").   Data cleansing is not an easy task.

The data entry operators in the Caribbean don't really read the addresses, they
just type real fast, copying letters instead of words.

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Bruce Black]

Michigan has a town called Hell and Pennsylvania has one called
Intercourse.


Intercourse, PA is very close to Blue Ball, PA.
In the Cayman Islands, they have a town named Hell (because of the 
strange, hellish rock formations there).  Their principle industry is 
the post office/gift shop, where you can mail post cards postmarked Hell. 


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/09/2005
   at 02:00 PM, Howard Brazee <[EMAIL PROTECTED]> said:

>I had a lawyer friend who was able to find a case where that
>amendment was enforced, believe it or not.   So it's not quite dead.

It's not dead, but the effect of the 14th Amendment was to make the
Bill of Rights binding on the states, not just on the Federal
government, and to give the Federal government the authority to
enforce the 14th Amendment on the states. That made the states less
autonomous than they had been. Subsequent court decisions also shifted
the balance of power.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Shmuel (Seymour J.) Metz]

In
<[EMAIL PROTECTED]>,
on 06/09/2005
   at 03:07 PM, "Perryman, Brian" <[EMAIL PROTECTED]> said:

>There was a famous case several years back (mid-1990s?) when AOL
>launched their services here in the UK and the signup process
>wouldn't accept anyone from Scunthorpe.

Michigan has a town called Hell and Pennsylvania has one called
Intercourse.

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

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Perryman, Brian]

Ah yes.. 

There was a famous case several years back (mid-1990s?) when AOL launched their 
services here in the UK and the signup process wouldn't accept anyone from 
Scunthorpe.



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Howard Brazee
Sent: 09 June 2005 14:58
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS:
RE: Userids]

I worked at a place that had a "dirty word file", that we used as part of the
logic that checked for valid addresses that people filled in.
This e-mail message is for the sole use of the intended recipient(s)and may 
contain confidential and privileged information of Transaction NetworkServices. 
 
Any unauthorized review, use, disclosure or distribution isprohibited.  If you 
are not the intended recipient, please contact thesender by reply e-mail and 
destroy all copies of the original message.

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Howard Brazee]

On  9-Jun-2005, [EMAIL PROTECTED] (Shmuel  Metz , Seymour J.) wrote:

> >Our U.S. Constitution of 1787 says that the laws of individual states
> > outrank wannabe laws of the national government except for the very
> >few  cases  specifically written in the same quaint document.
>
> That was the 10th Amendment as I recall.

I had a lawyer friend who was able to find a case where that amendment was
enforced, believe it or not.   So it's not quite dead.

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Howard Brazee]

On  8-Jun-2005, [EMAIL PROTECTED] (Jay Maynard) wrote:

> The length varies from state to state, from 6 (Texas being the best example)
> to 8 (California). There are also other restrictions: nothing obscene,
> nothing that looks like a sequential plate from one of a whole bunch of
> series, that kind of thing. Personalized plates (the politically correct
> term) vary in cost, from $20 or so up to over $100 per year on top of the
> registration fee.

I worked at a place that had a "dirty word file", that we used as part of the
logic that checked for valid addresses that people filled in.

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Howard Brazee]

On  8-Jun-2005, [EMAIL PROTECTED] (Perryman, Brian) wrote:

> I think I once read or was once told by someone that, in the US, you could
> have any vehicle licence plate as long as it was no more than eight
> characters, and didn't even have to be unique - by far and away the most
> popular being FOXYLADY..?

Different states have different limits.   Periodically I'll read where a state
changes to add an extra character to its standard.   More cars will do this.

Universal programing for license plates should probably have room for maybe 10
characters.  (This is a WAG, I'd have to do some research before putting it in
code).

One of the most tedious edits I remember doing was checking for valid postal
numbers - zip codes and the like - across the world.Someone would need to
maintain those edits as various countries make changes in their systems.

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/08/2005
   at 07:15 PM, "Keith E. Moe" <[EMAIL PROTECTED]> said:

>I have Mainframe vanity plates on both my vehicles.

Well, I have SPFH on mine, but I'm jealous of the guy that owns the
van with PEDANT. A friend has or had MVCK, after an encounter with bad
microcode.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/09/2005
   at 07:04 AM, Bill Fairchild <[EMAIL PROTECTED]> said:

>Our U.S. Constitution of 1787 says that the laws of individual states 
> outrank wannabe laws of the national government except for the very
>few  cases  specifically written in the same quaint document.

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

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

Re: REXX under TSO [WAS: TSO replacement? [WAS: RE: Userids]]

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 06/08/2005
   at 04:39 PM, Skip Robinson <[EMAIL PROTECTED]> said:

>Not too long after the original implementation, TSOE Rexx was
>enhanced to be able to use more customary I/O logic: OPEN, READ,
>READ,...CLOSE.

FSVO customary; it still supported only EXECIO and still didn't have
all of the EXECIO options that were available in VM/SP.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 06/08/2005
   at 11:50 PM, "Perryman, Brian" <[EMAIL PROTECTED]> said:

>I think I once read or was once told by someone that, in the US, you
>could have any vehicle licence plate as long as it was no more than
>eight characters, and didn't even have to be unique - by far and away
>the most popular being FOXYLADY..?

Usually called a "vanity plate". The rules vary from state to state.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Jay Maynard]

On Thu, Jun 09, 2005 at 07:04:39AM -0400, Bill Fairchild wrote:
> But  still the character string appearing on the plate must be unique
> within each state.  At least I have never heard of one of our states'
> allowing non-unique values in the vehicle license number field.

While this is pretty much true, there are exceptions, mainly official
vehicles (all city police cars in Minnesota have POLICE, for example) - but
Texas allows multiple vehicles with the same amateur radio callsign plates.

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Bill Fairchild]

In a message dated 6/8/2005 5:50:58 P.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

think I  once read or was once told by someone that, in the US, you could 
have any  vehicle licence plate as long as it was no more than eight 
characters, 
and  didn't even have to be unique 
 
Our U.S. Constitution of 1787 says that the laws of individual states  
outrank wannabe laws of the national government except for the very few  cases 
specifically written in the same quaint document.  Our national  judicial 
system 
still follows this precept on matters of no great  importance.  Consequently, 
each of our 50 states can have its own rules for  vehicle license ID.  
Depending 
on the total number of vehicles in any given  state that need to be licensed, 
the rule may allow from 6 to 8 characters.   E.g., California went from 6 to 
7 characters before any other state did, I  think, in the mid-1970s due to its 
being the most populous state.  But  still the character string appearing on 
the plate must be unique within each  state.  At least I have never heard of 
one of our states' allowing  non-unique values in the vehicle license number 
field.
 
The most unforgettable vanity plate I ever saw was "KGB SPY" in the late  
1970s on the George Washington Parkway not very far from the C.I.A.  
headquarters, of all places.
 
Bill Fairchild

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Dave Cartwright]

In the seventies at IBM Havant one of the sysprogs got a German transit
plate with the number MFT 11.

Sadly I am old enough to remember the judge's words at the Jeremy Thorpe
trial, commenting on one of the many unsavoury characters;
"The sort of man who has personalised number plates."

DC

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Gerhard Postpischil]

Ray Mullins wrote:

I saw that one.  That was one I wanted to get when I lived in California,
along with IFOX00 and IEV90, both of which were also taken.


I've had MVCK in Virginia and Vermont for many years. It serves as a 
reminder of errors in our 4341 (and later 4381) processors. TSO logon 
would get an 0C4; it seems MVCK failed when either operand crossed a 2K 
page boundary that was not a 4K boundary. IBM fixed it, and then it only 
failed when both operands crossed a 2K boundary. Good thing we had 
Wylbur to run in the meantime!


Gerhard Postpischil
Bradford, VT

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

IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Keith E. Moe]

I have Mainframe vanity plates on both my vehicles.

When I moved to California in 1976, it was to work for Amdahl, so I got NONIBM. 
(Remember, back then there wasn't Microsoft, Sun, etc.). I still 
have it, although on a some newer vehicle. And it's still appropriate, as I now 
work for BMC Software (2 months and counting).

My other vehicle has the name of my favorite exit in MVS: IKJEFLD.

Back in the late seventies, early eighties, my coworker got IEFBR14 as his 
license plate. He gave it up when he moved to Hong Kong.


Keith E. Moe
Laid Back Software, Inc.
http://www.laidbacksoftware.com
[EMAIL PROTECTED]
(408) 749-0655 (voice and FAX)
(408) 480-2067 (cell)

"We take our clients seriously, not ourselves."

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

Re: REXX under TSO [WAS: TSO replacement? [WAS: RE: Userids]]

[Skip Robinson]

EXECIO in the early TSOE days supported only reading an entire file into an
array in one shot. While VM seemed to have no gag reflex, TSOE would choke
of files of substantial size. It was also awkward to convert a CLIST to a
Rexx because the I/O logic was so different.

Not too long after the original implementation, TSOE Rexx was enhanced to
be able to use more customary I/O logic: OPEN, READ, READ,...CLOSE. This
fixed both the overload problem and the conversion problem.

.
.
.
JO.Skip Robinson
Southern California Edison Company
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]

IBM Mainframe Discussion List  wrote on 06/06/2005
17:00:00:

> ...
> I remember it becoming available in either 1991 or 1992 (early).
> ...
>
> I wrote my first REXX programme in 197x(??).
>
> I wrote my first TSO/REXX in 1990.
> EXECIO only supported FB80.
>
> -teD

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Jay Maynard]

On Wed, Jun 08, 2005 at 11:50:22PM +0100, Perryman, Brian wrote:
> I think I once read or was once told by someone that, in the US, you could
> have any vehicle licence plate as long as it was no more than eight
> characters, and didn't even have to be unique - by far and away the most
> popular being FOXYLADY..?

The length varies from state to state, from 6 (Texas being the best example)
to 8 (California). There are also other restrictions: nothing obscene,
nothing that looks like a sequential plate from one of a whole bunch of
series, that kind of thing. Personalized plates (the politically correct
term) vary in cost, from $20 or so up to over $100 per year on top of the
registration fee.

As it happens, the one thing I'd put on a personalized plate is something I
can get a lot cheaper than that...every US state allows ham radio operators
to get their callsign on their license plates, usually at a greatly reduced
cost (in Texas, it's $1/year additional).

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Perryman, Brian]

Ah.. I guess we're talking USA-specific stuff here again.. Oh well. 
 
I think I once read or was once told by someone that, in the US, you could have 
any vehicle licence plate as long as it was no more than eight characters, and 
didn't even have to be unique - by far and away the most popular being 
FOXYLADY..?
 
In the 51st State however, somewhat typically for a country where you need to 
have a licence to fish, shoot, watch TV, listen to the radio, keep a car on the 
road, keep a car OFF the road and, until only recently, own a dog, good ol' Her 
Majesty's Government impose a much stricter regime on us and you can only buy a 
licence plate ('registration number') that has actually been issued at some 
point, and also does not make the vehicle appear 'newer' than it actually is 
(all UK plates have a code letter denoting the year of registration of the 
vehicle).
 
There are several formats in the UK, depending on the age of the vehicle, and 
'useful' combinations are therefore limited but I enquired about S390 MVS only 
to be told it was still in use (allocated to a vehicle) and then, just to rub 
salt in the wounds, blow me if I didn't then see it driving around a month or 
two later..
 
 



From: IBM Mainframe Discussion List on behalf of Porowski, Ken
Sent: Wed 8/6/05 20:58
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: 
Userids]



Always had a preference for S22F myself ... did see IEF450I on a plate once.

-Original Message-
Jon Brock

I should get one that says 2086A04 or some such.  Or maybe DINO.

Jon


I saw that one.  That was one I wanted to get when I lived in California,
along with IFOX00 and IEV90, both of which were also taken.

I noticed that my vanity plate, which I released in 1991 and became
available in 1998, is still available.  I think I'll get it back when my
current plates expire.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
This e-mail message is for the sole use of the intended recipient(s)and may 
contain confidential and privileged information of Transaction NetworkServices. 
 
Any unauthorized review, use, disclosure or distribution isprohibited.  If you 
are not the intended recipient, please contact thesender by reply e-mail and 
destroy all copies of the original message.

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

Re: TSO replacement? [WAS: RE: Userids]

[Reed Starnes]

> >>BTW I would love to have MVS 310E as my car number plate
>
> >DB2 GUY
>
> Arnie Cashinghino, founder of the CBT Tape, had TURKEY for a license
> plate. The Turkey is the MVS symbol at SHARE.

Once while driving near LAX I saw SYSUT2.  I assume that was the
household's second car...



And that the first car was just like it?

I've been curious about the (probable) security administrator whom I've 
seen, also in the LA area, driving around with ICH408I.


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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Porowski, Ken]

Always had a preference for S22F myself ... did see IEF450I on a plate once.

-Original Message-
Jon Brock

I should get one that says 2086A04 or some such.  Or maybe DINO.

Jon


I saw that one.  That was one I wanted to get when I lived in California,
along with IFOX00 and IEV90, both of which were also taken.

I noticed that my vanity plate, which I released in 1991 and became
available in 1998, is still available.  I think I'll get it back when my
current plates expire.


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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE : Userids]

[Ed Finnell]

 
In a message dated 6/8/2005 1:40:54 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Now...  Let's see if it works from the mainframe...
old archaic relic  that it is.




Euuwweee...might go on to more productive pursuits.
I just remember it as 9,9,8(26 total) C1 is A, D1 is J and E2 is S.  Subtract 
x'40' for lower case.  

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE : Userids]

[Campbell Jay]

Now... Let's see if it works from the mainframe...
old archaic relic that it is.

C   D   E   
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF

 ABCDEFGHI   JKLMNOPQRSTUVWXYZ  

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Ed Finnell
Sent: Wednesday, June 08, 2005 1:47 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE :
Userids]


 
In a message dated 6/8/2005 12:44:34 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Something obviously threw your alignment  off



>>
So much fun, shouldn't have even tried. Thought if I did only spaces and  
fixed Font it would be OKAY, but NO! Have a good  one

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

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE : Userids]

[Ed Finnell]

 
In a message dated 6/8/2005 12:44:34 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Something obviously threw your alignment  off



>>
So much fun, shouldn't have even tried. Thought if I did only spaces and  
fixed Font it would be OKAY, but NO! Have a good  one

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE : Userids]

[Campbell Jay]

Something obviously threw your alignment off

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Ed Finnell
Sent: Wednesday, June 08, 2005 1:41 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE:
Userids]


 
In a message dated 6/8/2005 12:32:14 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

An IBM  PSR had C2D1C3 which were her initials in hex - it's still my
favorite (not  sure about the J, but the B and C are right). 




>>
C   DE 
0123456789abcdef0123456789abcdef0123456789abcdef
 ABCDEFGHI   JKLMNOPQR STUVWXYZ
 
TIC5ATIC.

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

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Ed Finnell]

 
In a message dated 6/8/2005 12:32:14 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

An IBM  PSR had C2D1C3 which were her initials in hex - it's still my
favorite (not  sure about the J, but the B and C are right). 




>>
C   DE 
0123456789abcdef0123456789abcdef0123456789abcdef
 ABCDEFGHI   JKLMNOPQR STUVWXYZ
 
TIC5ATIC.

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Powers, Carol A - CNF]

An IBM PSR had C2D1C3 which were her initials in hex - it's still my
favorite (not sure about the J, but the B and C are right).

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Jon Brock
Sent: Wednesday, June 08, 2005 10:17 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS:
RE: Userids]

I should get one that says 2086A04 or some such.  Or maybe DINO.

Jon



I saw that one.  That was one I wanted to get when I lived in
California, along with IFOX00 and IEV90, both of which were also taken.

I noticed that my vanity plate, which I released in 1991 and became
available in 1998, is still available.  I think I'll get it back when my
current plates expire.


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

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

Re: IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Jon Brock]

I should get one that says 2086A04 or some such.  Or maybe DINO.

Jon



I saw that one.  That was one I wanted to get when I lived in California,
along with IFOX00 and IEV90, both of which were also taken.

I noticed that my vanity plate, which I released in 1991 and became
available in 1998, is still available.  I think I'll get it back when my
current plates expire.


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

IBM MF-theme vanity plates (was RE: TSO replacement? [WAS: RE: Userids]

[Ray Mullins]

I saw that one.  That was one I wanted to get when I lived in California,
along with IFOX00 and IEV90, both of which were also taken.

I noticed that my vanity plate, which I released in 1991 and became
available in 1998, is still available.  I think I'll get it back when my
current plates expire.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Eric Chevalier
Sent: Wednesday June 08 2005 06:33
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: TSO replacement? [WAS: RE: Userids]

On 7 Jun 2005 16:44:28 -0700,
[EMAIL PROTECTED] (Leonard Woren) wrote:

>Once while driving near LAX I saw SYSUT2.  I assume that was the 
>household's second car...

And years ago, driving around the Marina Del Rey area of Los Angeles, I
spotted a car with the plates: "IEFBR14". Wonder what that person's favorite
computing platform was? :-)

Eric

--
Eric Chevalier  E-mail: [EMAIL PROTECTED]
   Web: www.tulsagrammer.com
Is that call really worth your child's life?  HANG UP AND DRIVE!

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

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

Re: TSO replacement? [WAS: RE: Userids]

[Eric Chevalier]

On 7 Jun 2005 16:44:28 -0700,
[EMAIL PROTECTED] (Leonard Woren) wrote:

>Once while driving near LAX I saw SYSUT2.  I assume that was the 
>household's second car...

And years ago, driving around the Marina Del Rey area of Los Angeles, I
spotted a car with the plates: "IEFBR14". Wonder what that person's
favorite computing platform was? :-)

Eric

--
Eric Chevalier  E-mail: [EMAIL PROTECTED]
   Web: www.tulsagrammer.com
Is that call really worth your child's life?  HANG UP AND DRIVE!

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

Re: REXX under TSO [WAS: TSO replacement? [WAS: RE: Userids]]

[Ed Gould]

on 6/6/05 7:00 PM, Ted MacNEIL at [EMAIL PROTECTED] wrote:

> ...
> I remember it becoming available in either 1991 or 1992 (early).
> ...
> 
> I wrote my first REXX programme in 197x(??).
> 
> I wrote my first TSO/REXX in 1990.
> EXECIO only supported FB80.
> 
> -teD
> (The secret to success is sincerity.
> If you can fake that,
> you've got it made!)

Ted,

REXX in TSO was only available somewhere around 1990 or later. I remember
distinctly as we were a bleeding edge custome for it not ESP but as soon as
it became available we installed it. I still remember talking with a TSO/e
rexx developer at GUIDE .

We found some interesting bugs . Unfortunetly its been almost 15 years and I
don't remember specifice PTF numbers.

REXX was available on VM for quite some time, I only ran VM 25+ years ago
and that was to run DOS (r26 IIRC) foi our NY office and that was on a
painfully slow 4331..

Ed
 

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

Re: TSO replacement? [WAS: RE: Userids]

[Leonard Woren]

> >>BTW I would love to have MVS 310E as my car number plate
>  
> >DB2 GUY
> 
> Arnie Cashinghino, founder of the CBT Tape, had TURKEY for a license
> plate. The Turkey is the MVS symbol at SHARE.

Once while driving near LAX I saw SYSUT2.  I assume that was the 
household's second car...


/Leonard

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

Re: REXX under TSO [WAS: TSO replacement? [WAS: RE: Userids]]

[Ted MacNEIL]

...
I remember it becoming available in either 1991 or 1992 (early).
...

I wrote my first REXX programme in 197x(??).

I wrote my first TSO/REXX in 1990.
EXECIO only supported FB80.

-teD
(The secret to success is sincerity.
If you can fake that,
you've got it made!)

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

Re: TSO replacement? [WAS: RE: Userids]

[Ed Gould]

on 6/6/05 7:54 PM, Shmuel Metz (Seymour J.) at [EMAIL PROTECTED]
wrote:

> In <[EMAIL PROTECTED]>, on
> 06/06/2005
> at 09:45 AM, "Horne, Jim - James S" <[EMAIL PROTECTED]> said:
> 
>> Rexx under TSO was available as of TSO v2.  On VM,it was available by
>> VM/SP release 3 - I don't think it was in release 2.
> 
> Are you sure? I know that REXX wasn't in SEPP (MVS/SE), but I thought
> that it was in MVS/SP R2 at the latest.
> 


I remember it becoming available in either 1991 or 1992 (early). I was
holding up another project as I wanted to do something in REXX that wasn't
avail;able in clist. My vague recollection that it was 2.4 (But I wouldn't
swear on it).

Ed

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

Re: TSO replacement? [WAS: RE: Userids]

[Bob Shannon]

>>BTW I would love to have MVS 310E as my car number plate
 

>A guy I worked with had

>DB2 GUY

Arnie Cashinghino, founder of the CBT Tape, had TURKEY for a license
plate. The Turkey is the MVS symbol at SHARE.

Bob Shannon

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

Re: TSO replacement? [WAS: RE: Userids]

[Ted MacNEIL]

...

BTW I would love to have MVS 310E as my car number plate
...

A guy I worked with had

DB2 GUY

Because of DB2, he went from an entry-level to a senior sysprog.


-teD
(The secret to success is sincerity.
If you can fake that,
you've got it made!)

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

Re: TSO replacement? [WAS: RE: Userids]

[Martin Packer]

Make that VLF rather than LLA. This week I can blame it on jetlag rather
than an actual "senior moment". Those are still ahead of me, I hope. :-)

Martin

Martin Packer, MBCS  CITPMartin Packer/UK/IBM
020-8832-5167 in the UK  (+44)   (MOBX 273643, Internal 7-325167, Mobile
07802-245584)

"Las cosas de palacio van despacio"

External Blog:
http://www-128.ibm.com/developerworks/blogs/dw_blog.jspa?blog=476
Internal Blog:
http://barney.adtech.internet.ibm.com/pilot/weblogs/comments/[EMAIL PROTECTED]

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

Re: TSO replacement? [WAS: RE: Userids]

[Horne, Jim - James S]

Respectfully, I must disagree.  The introduction of REXX was independent
of MVS introducing releases.  TSO V2 introduced REXX to the MVS world.
It did have a prerequisite of XA, not ESA.  When I went to work as a
contractor at a large azure, software/hardware manufacturer in 1990,
their MVS/XA systems had TSO V2 and I promptly proceeded to stun them by
putting some functions out under TSO that I had written in VM.  They
knew REXX was there but had not even tried to use it yet - they were all
still writing CLISTs.

Jim Horne
Lowe's Companies, Inc.

> 
> IIRC that was TSO V2R1M0. And that had a prereq of MVS 3.1.0e for
> the LLA
> cacheing of CLISTs/ REXX execs.

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

Re: TSO replacement? [WAS: RE: Userids]

[Martin Packer]

IIRC that was TSO V2R1M0. And that had a prereq of MVS 3.1.0e for the LLA
cacheing of CLISTs/ REXX execs.

BTW I would love to have MVS 310E as my car number plate. It must be out
there somewhere (in the UK). :-) But probably the actual car is in the
crusher by now. :-(

Martin

Martin Packer, MBCS  CITPMartin Packer/UK/IBM
020-8832-5167 in the UK  (+44)   (MOBX 273643, Internal 7-325167, Mobile
07802-245584)

"Las cosas de palacio van despacio"

External Blog:
http://www-128.ibm.com/developerworks/blogs/dw_blog.jspa?blog=476
Internal Blog:
http://barney.adtech.internet.ibm.com/pilot/weblogs/comments/[EMAIL PROTECTED]


   
 Ted MacNEIL   
 <[EMAIL PROTECTED] 
 BLACKBERRY.NET>To 
 Sent by: IBM  IBM-MAIN@BAMA.UA.EDU
 Mainframe  cc 
 Discussion List   
 <[EMAIL PROTECTED] Subject 
 .EDU> Re: TSO replacement? [WAS: RE:  
       Userids]
   
 07-06-05 01:00
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
   
   




...
>I don't remember seeing REXX under TSO until 3.1.0e.

V3R1 of what, MVS/SP or TSO/E? The version and release numbers were
not the same.
...

MVS/ESA 3.1.0e.

We jumped from XA 2.1.7 and it was there.
I didn't pay much attention about TSO/E and other releases.

-teD
(The secret to success is sincerity.
If you can fake that,
you've got it made!)

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

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

Re: TSO replacement? [WAS: RE: Userids]

[Ted MacNEIL]

...
>I don't remember seeing REXX under TSO until 3.1.0e.

V3R1 of what, MVS/SP or TSO/E? The version and release numbers were
not the same.
...

MVS/ESA 3.1.0e.

We jumped from XA 2.1.7 and it was there.
I didn't pay much attention about TSO/E and other releases.

-teD
(The secret to success is sincerity.
If you can fake that,
you've got it made!)

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

Re: TSO replacement? [WAS: RE: Userids]

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 06/05/2005
   at 12:00 AM, Ted MacNEIL <[EMAIL PROTECTED]> said:

>I don't remember seeing REXX under TSO until 3.1.0e.

V3R1 of what, MVS/SP or TSO/E? The version and release numbers were
not the same.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: TSO replacement? [WAS: RE: Userids]

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/05/2005
   at 09:32 AM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>If the argument to such commands is, properly, a session ID 
(TSU) as opposed to a user ID, 

TSUn is a jobid, not a session id, and did not exist when TSO
first came out. From OS/360 20.1 through OS/VS2 (SVS), TSO session
were controlled by the operating system; there was no separate JES.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: TSO replacement? [WAS: RE: Userids]

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
06/06/2005
   at 09:45 AM, "Horne, Jim - James S" <[EMAIL PROTECTED]> said:

>Rexx under TSO was available as of TSO v2.  On VM,it was available by
>VM/SP release 3 - I don't think it was in release 2.

Are you sure? I know that REXX wasn't in SEPP (MVS/SE), but I thought
that it was in MVS/SP R2 at the latest.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: TSO replacement? [WAS: RE: Userids]

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/06/2005
   at 08:26 AM, Mark Zelden <[EMAIL PROTECTED]> said:

>It was standard on MVS/ESA 3.  It was optional under MVS/XA 2.

It came as part of a separate program product, TSO/E. You could have
MVS/ESA without TSO/E, but there was a minimum level of TSO/E if you
wanted 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Userids

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Leonard Woren
> Sent: Friday, June 03, 2005 7:38 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Userids
> 
> 
> On Fri, Jun 03, 2005 at 03:00:01PM -0700, Skip Robinson 
> ([EMAIL PROTECTED]) wrote:
> > None of this is beyond the realm of comprehension or 
> manipulation, but you
> > have to build a business case for converting.
> 
> Here's my business case:



> (3) Ever need to update a UADS entry for a logged on user who doesn't 
> want to log off right now?

That's why IBM invented the CANCEL command.



> 
> That said, I have to admit that I've worked mostly in small 
> shops where
> I was the lead systems programmer *and* the de-facto security officer.
> And I generally set up clists & ISPF dialogs for userid 
> maintenance, so
> whether it's me or a security department doing it, the nitty gritty
> details are well hidden.  (Who can remember all the picayune little 
> steps to do to create a new userid?)

That's the way it is here. I'm the main CICS-z/OS-RACF person. Gott se
Danke that I don't need to worry about VTAM and Storage as well. And we
have a REXX program which does 99% of all userid related work.

> 
> 
> /Leonard
> 


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

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

Re: TSO replacement? [WAS: RE: Userids]

[Horne, Jim - James S]

Rexx under TSO was available as of TSO v2.  On VM,it was available by
VM/SP release 3 - I don't think it was in release 2.

Jim Horne
Lowe's Companies, Inc.

> 
> It was standard on MVS/ESA 3.  It was optional under MVS/XA 2.
> Some shops I was at had it, some didn't.

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

Re: TSO replacement? [WAS: RE: Userids]

[Mark Zelden]

On Sun, 5 Jun 2005 00:00:00 GMT, Ted MacNEIL
<[EMAIL PROTECTED]> wrote:

>...
>[1] All the way back to MVS/XA; my recollection is TSO/E 2.4, but
>ICBW.
>...
>
>I don't remember seeing REXX under TSO until 3.1.0e.
>
>But, I could be wrong.
>

It was standard on MVS/ESA 3.  It was optional under MVS/XA 2.
Some shops I was at had it, some didn't.

Mark
--
Mark Zelden
Sr. Software and Systems Architect
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

Re: Userids

[Ulrich Boche]

Eric Bielefeld wrote:

We still use UADS.  All new userids being set up in the last 5 or so years
go into RACF, but we have never converted all of the old ids from uads.
That leaves me as the only person at our shop who understands uads, and I
can't remember as well.  (I do know where to look though).

In our case, I doubt if I will ever convert uads, as our conversion away
from the mainframe is slated for this Thanksgiving.  All changes have been
frozen unless absolutely necessary.



From this discussion thread and also from my own experience with 
customers, my impression is that while very few RACF installations are 
still using UADS, the percentage of TopSecret installations using UADS 
is much higher. Is this impression wrong? If not, what might be the 
reason for this?

--
Ulrich Boche
SVA GmbH, Germany
IBM Premier Business Partner

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

Re: Userids

[Skip Robinson]

Once again, in the sole interests of exposition and full disclosure, my
ripostes are interspersed.

.
.
.
JO.Skip Robinson
Southern California Edison Company
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]

IBM Mainframe Discussion List  wrote on 06/03/2005
17:37:44:

> On Fri, Jun 03, 2005 at 03:00:01PM -0700, Skip Robinson (JO.Skip.
> [EMAIL PROTECTED]) wrote:
> > None of this is beyond the realm of comprehension or manipulation, but
you
> > have to build a business case for converting.
>
> Here's my business case:
> (1) Don't have to keep two things in sync (UADS, RACF).

I'm a passionate advocate of not having to sync up data in multiple places:
the clock ticks away toward the moment when time and space skew out of
whack. But it appears that *nothing* in UADS and RACF require synchronizing
once the userids are defined. Other than the userid itself, there seem to
be *no* intersecting attributes.

> (2) Easier to hand it all off to the security department.

Here's the major rub. Our security department has spent the past few
decades managing UADS. Not managing it directly, mind you, but with tools
and utilities that we spawned over time in the face of the gawd awful
complexity of the various commands required. It's *change* that would be
difficult to 'hand off'.

> (3) Ever need to update a UADS entry for a logged on user who doesn't
> want to log off right now?

Coffee breaks. Bathroom breaks. Catching up on email. How else would we
ever get around to the important stuff?

> (4) Ever need to compress and/or expand UADS?  Unless you like to
> live on the edge (doesn't usually bother me, YMMV), this requires
> stand-alone time.

Hmmm. Sounds like a task you assign to the tush-pain who's begging for a
peg or two notch-down in the group pecking order. Maybe it's senioritis
(and I don't mean the lovable springtime hormonal kind), but I don't
remember ever having to do that.

> (5) Is UADS really shareable?

Not sure if this question is technical, philosophical, or a suggestion for
a twisted-geek Oprah show. I think the answer is Yes on technical grounds,
based on our experience sharing UADS within a sysplex. Other nuances are
left as an exercise for the reader.

> (6) Since in a security-system-down scenario, having workable emergency
> ids in UADS is critical, I prefer to limit exposure to having UADS
> messed up by eliminating updates to it.

I suppose that even-once-in-my-entire-career having suffered this scenario,
I might get worked up. But outside of B-movie horror shows, it seems more
like twisted fantasy than a line item in a Disaster Recovery plan.

> (7) Aren't there TSO features which can't be utilized at all by
> UADS-defined users?

Yes, but the only one that has motivated us to create some RACF TSO
segments is the TSOE OPERATOR command, which is *extraordinarily* useful
for (mostly batch) Rexx execs that perform some very nifty automation. We
have done that for a few sysprog userids. After counting them all, I still
have a finger or two left on the enumerator hand. If IBM really wanted to
make life easier on customers, they could simply remove this silly
restriction.

>
> That said, I have to admit that I've worked mostly in small shops where
> I was the lead systems programmer *and* the de-facto security officer.
> And I generally set up clists & ISPF dialogs for userid maintenance, so
> whether it's me or a security department doing it, the nitty gritty
> details are well hidden.  (Who can remember all the picayune little
> steps to do to create a new userid?)
>

Ditto, ditto, and ditto. But once all those clists and dialogs are
established and in use--and don't forget our menagerie of COBOL
programs--change is complicated in proportion to the sophistication of the
detail-hiding mechanisms. If I could wave a hand and transform UADS into
TSO segments, it would have been done long ago. But I'm reluctant to wave a
hand only to pull back a bloody stump. A tough sell for workers comp.

>
> /Leonard

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

Re: TSO replacement? [WAS: RE: Userids]

[Ted MacNEIL]

...
[1] All the way back to MVS/XA; my recollection is TSO/E 2.4, but
ICBW.
...

I don't remember seeing REXX under TSO until 3.1.0e.

But, I could be wrong.

I used it under VM/CMS since the mid-to-late 1970's.


[EMAIL PROTECTED]

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

Re: TSO replacement? [WAS: RE: Userids]

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/03/2005
   at 11:03 AM, andrew mcintyre <[EMAIL PROTECTED]> said:

>The TSO host command environment has been in REXX for years and
>years. It's documented as far back as OS/390 V2R4 and probably
>further.

An environment to allow REXX to issue TSO commands was in TSO/E as
long as REXX was[1], but it was limited to code running under the TMP,
whether background or foreground. I believe that the new environment
allows REXX code not running under the TMP to issue TSO commands.

[1] All the way back to MVS/XA; my recollection is TSO/E 2.4, but
ICBW.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: TSO replacement? [WAS: RE: Userids]

[Paul Gilmartin]

In a recent note, Walt Farrell said:

> Date: Sun, 5 Jun 2005 07:45:19 -0400
> >
> > Now, suppose support were added to run 3270 OMVS directly from a tn3270
> > connection, with no TSO involvement.  Then a given user could run
> > several 3270 OMVS sessions, since the TSO one-session-per-user limit
> > would not apply.
> 
> time and money doing it.  There are always some questions to answer,
> such as "which TSO session should a SEND command choose", but those
> 
Such questions, including the related, "which session should an
operator's CANCEL command choose," are predicated on the confusion
of session ID with user ID.  If the argument to such commands is,
properly, a session ID (TSU) as opposed to a user ID, the effect
of the command should be directed to that session.  The possibility
remains that a user ID could be supplied as the argument, in which
case the message should be sent to all sessions owned by that user,
or all sessions owned by that user should be cancelled.

This is all similar to the same conceptual error that gave rise
to Barry Merrill's tale (likely apocryphal) of the confusion
that arose when Alan Scheer caused responses that should have
been directed to a session ID to be misdirected instead to a
user ID.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: TSO replacement? [WAS: RE: Userids]

[Walt Farrell]

On 6/2/2005 12:54 PM, Paul Gilmartin wrote:

In a recent note unmask]> said:



Date: Thu, 2 Jun 2005 09:12:36 -0700

If anything, maybe someone thought that the shell environment for z/OS
UNIX (back then called MVS Open Edition) would be a viable replacement.
In some ways it is.



A fantasy, based on this.

With z/OS 1.5, Rexx now has the "address TSO" environment, which starts
a captive TSO TMP address space (with no display).  There's no reason
one can't have such a captive TMP address space for each linemode shell
session.

Now, suppose support were added to run 3270 OMVS directly from a tn3270
connection, with no TSO involvement.  Then a given user could run
several 3270 OMVS sessions, since the TSO one-session-per-user limit
would not apply.

Then suppose some combination of "address TSO" and "address SYSCALL pt3270"
(the latter now used to support OEDIT and OBROWSE) allowed the user to
bring up a captive TMP address space (as above), but _with_ the 3270
display active.

The best of both worlds?

I'm sure Walt Farrell will say it can't be done; Jim Mulder would be
more sympathetic.


No; I think that could probably be done, if someone wanted to invest the 
time and money doing it.  There are always some questions to answer, 
such as "which TSO session should a SEND command choose", but those 
could be worked around somehow.


The big question is time and money.

Walt

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

Re: Userids

[Leonard Woren]

On Fri, Jun 03, 2005 at 03:00:01PM -0700, Skip Robinson ([EMAIL PROTECTED]) 
wrote:
> None of this is beyond the realm of comprehension or manipulation, but you
> have to build a business case for converting.

Here's my business case:
(1) Don't have to keep two things in sync (UADS, RACF).
(2) Easier to hand it all off to the security department.
(3) Ever need to update a UADS entry for a logged on user who doesn't 
want to log off right now?
(4) Ever need to compress and/or expand UADS?  Unless you like to 
live on the edge (doesn't usually bother me, YMMV), this requires
stand-alone time.
(5) Is UADS really shareable?
(6) Since in a security-system-down scenario, having workable emergency
ids in UADS is critical, I prefer to limit exposure to having UADS
messed up by eliminating updates to it.
(7) Aren't there TSO features which can't be utilized at all by
UADS-defined users?

That said, I have to admit that I've worked mostly in small shops where
I was the lead systems programmer *and* the de-facto security officer.
And I generally set up clists & ISPF dialogs for userid maintenance, so
whether it's me or a security department doing it, the nitty gritty
details are well hidden.  (Who can remember all the picayune little 
steps to do to create a new userid?)


/Leonard

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

Re: Userids

[Skip Robinson]

OK, it's time to speak up on behalf of us mossback Luddites who are still
mired in UADS. The reasons for not converting to modern methods may be
BUSINESS rather than technology oriented. I don't doubt that any number of
mechanisms exist to turn a particular SYS1.UADS into (say) RACF TSO
segments. That takes care of Day 1 of the New Era. How about Day 2, Day
200, etc. In other words, how do you manage RACF defined userids?

- Create new
- Modify existing
- Query
- Delete

For both Create and Modify, you have several 'attributes' to deal with:

- Account numbers
- Logon procs
- Authority to submit jobs, force a tape mount under TSO, or use the TSO
OPER command

For Query, you have the problem of displaying all of the above 'attributes'
of a userid in a succinct and intelligible manner. As much as we all like
to dis UADS, all of this information lives in one spot: the userid entry.
In a single LIST command, you can see everything at a glance.

With RACF TSO segments, this stuff lives all over the map. Relatively
little resides in the segment itself; most is expressed as PERMIT authority
to profiles in a menagerie of classes, some of which are mercifully obvious
(TSOAUTH TSOPROC), while others force you to memorize (ACCTNUM).

None of this is beyond the realm of comprehension or manipulation, but you
have to build a business case for converting. 'Modern' doesn't fly very far
in persuading *other* people to spend time and money on a project. For
example, we currently have an elaborate process to manage userids across
multiple platforms. To switch from UADS to RACF segments, that process
would have to be modified extensively. (The line between 'elaborate' and
'labyrinthine' is fuzzy.) What's the motivation? Who foots the bill for
conversion and training?

In a previous shop, each application programmer had lots of account numbers
to track time spent on various projects. With UADS, we could see at a
glance which projects (account numbers) a userid was authorized for. That
simple query in the world of TSO segments is a programming exercise.

None of this is a hard case for sticking with UADS. Just an observation
that failure to convert is not necessarily silly or Neanderthal.

.
.
.
JO.Skip Robinson
Southern California Edison Company
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]

IBM Mainframe Discussion List  wrote on 06/02/2005
18:19:11:

> Oh my gosh, I thought we were the last company to convert from UADS to
> external security (TSS last year).  It's mystifying why anyone would
> "outvote" you on this count.  We were years and years overdue but we're
> certainly not looking back.
>
> I've done several of these conversions, each with the popular 3 ESMs, all
> but the last were easy, transparent, and gradually phased in.
>
> My sympathies,



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

Re: TSO replacement? [WAS: RE: Userids]

[Paul Gilmartin]

In a recent note, andrew mcintyre said:

> Date: Fri, 3 Jun 2005 12:42:02 -0400
> >
> > Note the revision bars.  Compare to edition for z/OS 1.3, or in
> 
> I had seen that in the USS manuals but outside of USS, does it have any use?
> 
Why does that matter?

The topic of the thread is "TSO Replacement".  Unix Services was
cited (not exactly proposed) (not initially by me) as a replacement
candidate.  Another set of respondents (with considerable overlap)
noted the need for continued availability of the venerable TSO
services.  "address 'TSO' whatever" provides such availability
in Unix Services, with the significant advantage over /bin/tso
that it's possible to issue more than one TSO command within the
lifespan of the spawned TSO address space.  (e.g. ALLOCATE; CALL).

Small steps are being made toward a TSO alternative.  We're not
there yet.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: TSO replacement? [WAS: RE: Userids]

[andrew mcintyre]

>Linkname: The TSO command environment
> URL: http://publibz.boulder.ibm.com/cgi-
> bin/bookmgr_OS390/BOOKS/BPXZB630/1.4?SHELF=EZ2ZO110&DT=20020620115828
> 
> Note the revision bars.  Compare to edition for z/OS 1.3, or in

I had seen that in the USS manuals but outside of USS, does it have any use?


Andrew McIntyre - Senior I/T Specialist - certified
zSeries Software Technical Sales
SMPO (Software Migration Project Office)
TMT (Tivoli Migration Team)
404-487-2477 or tie 546-2477
[EMAIL PROTECTED]

SMPO
 http://www.ibm.com/software/solutions/softwaremigration
NetView for z/OS
 http://www.ibm.com/tivoli/products/netview-zos/resources/nv390-update.html
System Automation for z/OS
 http://www.s390.ibm.com/sa


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

Re: TSO replacement? [WAS: RE: Userids]

[andrew mcintyre]

> Where does that say ASCII? 

It says it here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D341/6.1.7?SHEL
F=F1A1BK51&DT=20050121145751

> Where does that say Curses and ASCII?

It doesn't. However, there are many open source versions of Curses for X11.


Andrew McIntyre - Senior I/T Specialist - certified
zSeries Software Technical Sales
SMPO (Software Migration Project Office)
TMT (Tivoli Migration Team)
404-487-2477 or tie 546-2477
[EMAIL PROTECTED]

SMPO
 http://www.ibm.com/software/solutions/softwaremigration
NetView for z/OS
 http://www.ibm.com/tivoli/products/netview-zos/resources/nv390-update.html
System Automation for z/OS
 http://www.s390.ibm.com/sa


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

Re: TSO replacement? [WAS: RE: Userids]

[Paul Gilmartin]

In a recent note, andrew mcintyre said:

> Date: Fri, 3 Jun 2005 11:03:56 -0400
> 
> > With z/OS 1.5, Rexx now has the "address TSO" environment, which starts
> > a captive TSO TMP address space (with no display).
> 
> The TSO host command environment has been in REXX for years and years. It's
> documented as far back as OS/390 V2R4 and probably further.
> 
I stand slightly corrected.  It was z/OS 1.4.  See:

   Linkname: The TSO command environment
URL: 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB630/1.4?SHELF=EZ2ZO110&DT=20020620115828

Note the revision bars.  Compare to edition for z/OS 1.3, or in


   CHANGES Summary of changes

   Summary of changes
   for SA22-7806-03
   z/OS Version 1 Release 4

   This document contains information previously presented in z/OS Using
   REXX and z/OS UNIX System Services, SA22-7806-02, which supports z/OS
   Version 1 Release 3.

   New information

   [ ... ]

 * Support for a TSO host command environment that permits a REXX
   program to run TSO/E commands.

It never worked prior to that; it was sorely missed.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: TSO replacement? [WAS: RE: Userids]

[Paul Gilmartin]

In a recent note, andrew mcintyre said:

> Date: Fri, 3 Jun 2005 10:57:24 -0400
> 
> > Make this specifically run time libraries for X11 and Curses in ASCII mode.
> 
> Hasn't that already been done?
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D341/6.0?SHELF=F1A1BK51&DT=20050121145751
> 
Where does that say ASCII?

Where does that say Curses and ASCII?

Last time I tried building either an X11 application or a Curses
application in ASCII mode, it failed.  An IBM employee told me
(in PMR or on MVS-OE LISTSERV, I forget which) that each was
unsupported in ASCII.  I'd love to learn that this has changed,
but not optimistc enough to spend much effort retrying.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: TSO replacement? [WAS: RE: Userids]

[andrew mcintyre]

> With z/OS 1.5, Rexx now has the "address TSO" environment, which starts
> a captive TSO TMP address space (with no display).  

The TSO host command environment has been in REXX for years and years. It's
documented as far back as OS/390 V2R4 and probably further.

Unless you are talking about something completely new that I'm missing.


Andrew McIntyre - Senior I/T Specialist - certified
zSeries Software Technical Sales
SMPO (Software Migration Project Office)
TMT (Tivoli Migration Team)
404-487-2477 or tie 546-2477
[EMAIL PROTECTED]

SMPO
 http://www.ibm.com/software/solutions/softwaremigration
NetView for z/OS
 http://www.ibm.com/tivoli/products/netview-zos/resources/nv390-update.html
System Automation for z/OS
 http://www.s390.ibm.com/sa


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

Re: TSO replacement? [WAS: RE: Userids]

[andrew mcintyre]

> Make this specifically run time libraries for X11 and Curses in ASCII mode.

Hasn't that already been done?
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D341/6.0?SHELF=
F1A1BK51&DT=20050121145751


Andrew McIntyre - Senior I/T Specialist - certified
zSeries Software Technical Sales
SMPO (Software Migration Project Office)
TMT (Tivoli Migration Team)
404-487-2477 or tie 546-2477
[EMAIL PROTECTED]

SMPO
 http://www.ibm.com/software/solutions/softwaremigration
NetView for z/OS
 http://www.ibm.com/tivoli/products/netview-zos/resources/nv390-update.html
System Automation for z/OS
 http://www.s390.ibm.com/sa


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

Re: Userids

[Eric Bielefeld]

We still use UADS.  All new userids being set up in the last 5 or so years
go into RACF, but we have never converted all of the old ids from uads.
That leaves me as the only person at our shop who understands uads, and I
can't remember as well.  (I do know where to look though).

In our case, I doubt if I will ever convert uads, as our conversion away
from the mainframe is slated for this Thanksgiving.  All changes have been
frozen unless absolutely necessary.

Eric Bielefeld
P&H Mining Equipment

On Thu, 2 Jun 2005 20:19:11 -0500, Tony Babonas <[EMAIL PROTECTED]>
wrote:

>Oh my gosh, I thought we were the last company to convert from UADS to
>external security (TSS last year).  It's mystifying why anyone would
>"outvote" you on this count.  We were years and years overdue but we're
>certainly not looking back.
>
>I've done several of these conversions, each with the popular 3 ESMs, all
>but the last were easy, transparent, and gradually phased in.
>
>My sympathies,
>tb

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