TRSMAIN and abendb37-4 on temporary dataset

[Itschak Mugzach]

I am using TRSMAIN to unpack into a pds. The Tresed file is quit large and
the job abends with av37-4 on a temporary dataset that is allocated by
TRAMAIN (DD-SYS3). Preallacting the dataset cause TRSMAIN to try to
allocate the next dataset (and abend again). I also tried to change the
alloc00 parmlib member and IPL again with help.

How can I recover from this stupid abend?

Itschak

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

Re: TRSMAIN and abendb37-4 on temporary dataset

[Norbert Friemel]

On Mon, 2 Nov 2009 11:04:22 +0200, Itschak Mugzach wrote:

>I am using TRSMAIN to unpack into a pds. The Tresed file is quit large and
>the job abends with av37-4 on a temporary dataset that is allocated by
>TRAMAIN (DD-SYS3). Preallacting the dataset cause TRSMAIN to try to
>allocate the next dataset (and abend again). I also tried to change the
>alloc00 parmlib member and IPL again with help.
>
>How can I recover from this stupid abend?

Is your input file striped or compressed (extended format)?
http://www-01.ibm.com/support/docview.wss?uid=isg1OA22765


Norbert Friemel

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

Re: TRSMAIN and abendb37-4 on temporary dataset

[Itschak Mugzach]

Thanks Norbert. This is it...

Itschak

On Mon, Nov 2, 2009 at 11:34 AM, Norbert Friemel  wrote:

>  On Mon, 2 Nov 2009 11:04:22 +0200, Itschak Mugzach wrote:
>
> >I am using TRSMAIN to unpack into a pds. The Tresed file is quit large and
> >the job abends with av37-4 on a temporary dataset that is allocated by
> >TRAMAIN (DD-SYS3). Preallacting the dataset cause TRSMAIN to try to
> >allocate the next dataset (and abend again). I also tried to change the
> >alloc00 parmlib member and IPL again with help.
> >
> >How can I recover from this stupid abend?
>
> Is your input file striped or compressed (extended format)?
> http://www-01.ibm.com/support/docview.wss?uid=isg1OA22765
>
>
> Norbert Friemel
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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

Alternatives to QuickRef?

[Itschak Mugzach]

Does anyone knows an alternative to the mainframe product known as QuickRef?


ITschak

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

Re: Alternatives to QuickRef?

[Michael Knigge]

Itschak Mugzach schrieb:

Does anyone knows an alternative to the mainframe product known as QuickRef?


I' currently working on a "Help-System" that will hopefully be released 
Q1 next year (most of the work is done - I'm currently cleaning up some 
things, implement licesnsing stuff, design the web-site and so on).


This system is a .NET Application that can be hooked into any running 
application, grab the text string under the cursor and query a DB with 
this string.


This way I can query any 3270-Emulation and query for the string under 
the cursor. (In detail, I use several techniques/methods to get the 
string to query).



If you are interested to give it a test drive or you want to have more 
technical details - let me know. And also let me know which manuals you 
need to be stored in the database (i. e. SQL-Codes, DB2-Messages, 
RACF-Messages. MVS System Codes and so on).


I also plan to provide an API so you can store your own personal data 
into the database.




Oh.. and to answer your question: Well, the only alternative that I know 
is IBM BookManager



Bye,
Michael

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

SV: An Alternative Modest PARM Proposal

[Thomas Berg]

If the current JCL PARM format change from HW + 0-100 bytes 
to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
are there any backward compatibility problems ?

 

Regards, 
Thomas Berg 
__ 
Thomas Berg   Specialist   IT-U   SWEDBANK 



 

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] För Shmuel Metz (Seymour J.)
> Skickat: den 1 november 2009 18:56
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: An Alternative Modest PARM Proposal
> 
> In , on 10/30/2009
>at 05:42 PM, "Robert A. Rosenberg"  said:
> 
> >OK. The current standard is a single FW (with the high bit set)  
> >pointing at a HW with length followed by 0-100 bytes of data 
> (the FW  
> >being pointed to by R1).
> 
> No, the current standard is that bit 0 indicates the end of 
> the list and that the first word points to a halfword length 
> followed by characters.
> The 100 character limit is strictly a C/I limited, and 
> various IBM utilities accept longer parms.
> 
> >Make the new method a 2 FW Parm list with FW 1 pointing at 
> the old  100 
> >character PARM and FW 2 (which is End of Parmlist flagged)  
> pointing at 
> >the new Long Parm.
> 
> That would break compatibility badly.
> 
> >BTW: There are a number of IBM utilities that ALREADY check 
> the  length 
> >of their Parmlist since they support being launched by JCL  
> with a PARM 
> >and being CALLED with a real muli-parm parmlist (the 2nd  and 
> >subsequent parms often being DDN overrides).
> 
> Which is one of the reasons why your suggestion won't fly.
> 
> BTW, I had forgotten about an old (1995) post from Don Ault 
> in which he said that IBM will not implement long parms in a 
> fashion incompatible with the existing interface. He left it 
> open as to whether the length field would be signed or unsigned.
> 
> -- 
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 
> instructions, send email to lists...@bama.ua.edu with the 
> message: GET IBM-MAIN INFO Search the archives at 
> http://bama.ua.edu/archives/ibm-main.html
> 

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

Re: What SVCs are in use?

[larry macioce]

If you have CAs Datacom you can look it up using dbutlty
mace


On Fri, Oct 30, 2009 at 10:24 AM, Mark Zelden wrote:

> I know how you do it with TASID.  I was asking how you do it
> with ISRDDN as you suggested.
>
> Regards,
>
> Mark
> --
> Mark Zelden
> Sr. Software and Systems Architect - z/OS Team Lead
> Zurich North America / Farmers Insurance Group - ZFUS G-ITO
> mailto:mark.zel...@zurichna.com
> z/OS Systems Programming expert at
> http://expertanswercenter.techtarget.com/
> Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
>
>
>
> On Fri, 30 Oct 2009 12:09:14 -0200, carlos roberto visconde
>  wrote:
>
> >In TASID you choose "Miscellaneous displays" and then "SVC - SVC list"
> >
> >
> >2009/10/29 Mark Zelden 
> >
> >> Without chasing though control blocks?  Are you sure your not
> >> confusing it with ISRDDN's big brother TASID?
> >>
> >> Mark
> >> --
> >> Mark Zelden
> >> Sr. Software and Systems Architect - z/OS Team Lead
> >> Zurich North America / Farmers Insurance Group - ZFUS G-ITO
> >> mailto:mark.zel...@zurichna.com
> >> z/OS Systems Programming expert at
> >> http://expertanswercenter.techtarget.com/
> >> Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
> >>
> >>
> >> On Thu, 29 Oct 2009 17:31:11 -0200, carlos roberto visconde
> >>  wrote:
> >>
> >> >You can use TSO ISRDDN.
> >> >
> >> >
> >> >
> >> >2009/10/28 Ward, Mike S 
> >> >
> >> >> Hello all, can someone point me to a manual or command that will show
> >> >> what SVCs are actually in use? I looking in ieasvcxx, but that only
> >> >> shows what user/vendor supplied SVCs are used. Thanks in advance.
> >> >> ==
> >> >> This email and any files transmitted with it are confidential and
> >> intended
> >> >> solely for the use of the individual or entity to which they are
> >> >> addressed. If you have received this email in error please notify the
> >> >> system manager. This message contains confidential information and is
> >> >> intended only for the individual named. If you are not the named
> >> >> addressee you should not disseminate, distribute or copy this e-mail.
> >> >> Please notify the sender immediately by e-mail if you have received
> >> >> this e-mail by mistake and delete this e-mail from your system. If
> you
> >> >> are not the intended recipient you are notified that disclosing,
> >> copying,
> >> >> distributing or taking any action in reliance on the contents of this
> >> >> information is strictly prohibited.
> >> >>
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> >> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >>
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> >Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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

ICSF EMV.

[Luis Moreno]

We are currently developing the implementation of EMV ICSF. We wants to hear
about any experience managing ARQC cryptograms and ARPC.

Thanks in advance. 

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

Re: An Alternative Modest PARM Proposal

[Binyamin Dissen]

On Mon, 2 Nov 2009 13:40:44 +0100 Thomas Berg  wrote:

:>If the current JCL PARM format change from HW + 0-100 bytes 
:>to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
:>are there any backward compatibility problems ?

Not at all.

Would require a CVT bit to indicate the new support.

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: Dynamic Lnklst Changes

[Joel C. Ewing]

Certainly a  very strong argument against ever performing UPDATE=*.  I
appreciate the clarification, but certainly don't like the answer.
Without some idea about what z/OS services or subsystems might make
unwarranted assumptions about old lnklst control structures, the user or
other vendors are in no position to make a rational assessment about
whether even an update on a specific running address space poses an
imminent danger to the system.  If UPDATE can only be used when an
unplanned IPL at some arbitrary point in the future can be tolerated,
that would pretty well eliminate the usefulness of this option on a
production system.  If the risk could be isolated to the updated address
space, that might be acceptable; but if it puts arbitrary address spaces
or the entire system at risk, that is not.

>From our usage of this in the past (before the risks were advertised), I
would question the assumption that in the majority of cases it would not
be a requirement, or at least highly useful if running address spaces
could be updated - TSO user communities running ISPF-based applications,
and in some cases CICS-regions come to mind.  Back before lnklst PDSEs
were common and before we were aware of risks, we even did UPDATE=*
several times a year to roll in revisions and free up obsolete lnklst
datasets where the intent was definitely to affect running address
space.  We might rename an old dataset that was removed from lnklst, but
were careful to never delete or move such datasets until after the next
IPL.  I guess we were just lucky, but we never saw any adverse system
behavior from this practice.
  JC Ewing

On 11/01/2009 08:13 AM, Peter Relson wrote:
> The page-fault-driven loading case from PDSE was addressed many years ago.
> It was not done solely for integrity reasons. It was addressed by not doing
> page-fault-driven loading at all for LNKLST fetches.
> 
> The problem that will exist forever is references to the control structures
> that will no longer be valid (or no longer be recognized as being part of a
> LNKLST, for which special rules apply) once a LNKLST update has been made.
> Can you guarantee, no matter how long you wait, that no address space
> relies on those structures? Not usually. A delay makes it less likely that
> an operation is still in progress, but by no means eliminates the
> possibility. And these references, I believe, might not even be limited to
> within the scope (for example) of a LOAD or similar operation, especially
> when program objects / PDSEs are involved. That is a recollection; I don't
> have concrete examples to share.
> 
> The safe thing to do is not to use UPDATE.  In the majority of cases,
> LNKLST updates are needed only by newly started programs, not existing ones
> (for which case no UPDATE is needed or appropriate). The rules are what the
> rules are. They will not change. It's your system, so you can choose to
> follow them or not at your own risk. But you should not expect subsequently
> to be able to complain about problems that happen to arise as a result.
> 
>> When the changes in the
>> link list only involve user or installation code, there is a much higher
>> likelihood that you would understand the way the code is used and
>> whether there are interdependencies that would be a problem
> And in that case it is much more likely that the update is needed only by
> programs that start (or are restarted) after this point, so no UPDATE is
> needed.
> 
> FWIW, an integrity issue caused by "improper" usage by an authorized user
> is to be dealt with by the user. The system for the most part has no
> alternative but to do what it has been told to do, as the authorized issuer
> could do it itself without cooperation by the operating system if it chose
> to..
> 
> Peter Relson
> z/OS Core Technology Design



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

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

Re: FTP PUT with Store Unique

[Miller, Pat]

Thank you, Bill and Chris, for explaining the not-...@#$%ing-obvious. It
would appear that some of the application programmers whom I've been
admonishing to be more explicit than "A processing error has occurred"
have been advising the FTP developers in their considerable spare time
on how to handle error conditions.  I'll whip up a little REXX to insert
a date/time stamp into the name before the FTP step. 

I foolishly assumed when I saw the SUnique parameter that - of course! -
this was a need that many people must have and a way to handle it is
right there in the standard FTP functionality. But apparently, if you
want something done right, you have to DIY.

Thanks, again guys.



-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Chris Mason
Sent: Saturday, October 31, 2009 12:17 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FTP PUT with Store Unique

Pat

The best list for topics related to the Communications Server (CS) IP 
component is IBMTCP-L:

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

-

> The IP User's Guide & Commands ... seems pretty straightforward on
this.

Actually, it all seems anything but "pretty straightforward" to me - or
maybe 
I'm being massively thick. See my attempted rewrite of the section for
which 
you so carefully provided URL references below.

On seeing your post, my proposed next step was to check the RFC but, 
thankfully, I noticed Bill Godfrey's contribution first - and this post
is an 
extension of his.

What the CS IP User's Guide and Commands description of SUNIQUE says is 
abysmally unclear - and criminally remiss in not pointing out that the
"NAME" 
option is, in effect, "an outlaw"!

Let's try the following:



SUnique subcommand - Toggles the storage method

Purpose

The SUnique subcommand changes the method of storing files on the
foreign 
host so that the store-unique (STOU) command is used rather than the
store 
(STOR) command or vice versa.

Format

SUnique On Off NAME NONAME

Parameters

On
Turns on "store unique".

Off
Turns off "store unique".

NAME
Instructs the FTP client to include a name with the STOU command. NAME 
must be specified following ON or OFF.

NONAME
Instructs the FTP client not (italics) to include a name with the STOU 
command. NONAME must be specified following ON or OFF. This is the
option 
which complies with RFC 959.

Usage

- By default, the SUnique setting is OFF NAME.

- When "store unique" is turned off, FTP uses a store command (STOR)
with 
the PUt and MPut subcommands. Following the STOR command is a name 
string specified by the foreign_file value. The data set or file created
at the 
foreign host has the name specified by the foreign_file value. If the
foreign 
host already had a data set or file with the name specified by the
foreign_file 
value, the foreign host overwrites the existing data set or file.

- When "store unique" is turned on, FTP uses a store-unique command
(STOU) 
with the PUt and MPut subcommands.

-- If NONAME is in effect, no name string specifying a foreign_file
value follows 
the STOU command. The created foreign data set or file is stored with an

unique name. The FTP server sends the unique name of the created foreign

data set or file to the FTP client, where the data set or file name is
presented 
in a message identified with prefix ?.

-- If NAME is in effect, the name string specifying a foreign_file value
follows 
the STOU command.

If the foreign host, the FTP server, does not support the presence of a 
parameter, the name string, following the STOU command, it will reject
the 
STOU command and the following message is presented:

501 'STOU ': Invalid number of parameters

where  is the unacceptable foreign_file value.

If the foreign host does support the presence of a foreign_file value 
parameter, and does not (italics) already have a data set or file with
the name 
specified by the foreign_file value, the data set or file created at the
foreign 
host has the name specified by the foreign_file value.

If the foreign host does support the presence of a foreign_file value 
parameter, and does already have a data set or file with the name
specified 
by the foreign_file value, the response of the foreign host depends upon
the 
particular implementation of the FTP server. An example of such a
response 
could be to reject the STOU command. 

-

Note how use of the store-unique command prevents you from overwriting
or 
erasing the existing data set or file on the foreign host. 

- If the FTP server to which you are sending files implements RFC 959,
"File 
Transfer Protocol", strictly, only the following can be specified when 
enabling "store unique":

SUNIQUE ON NONAME

- SUnique with no parameters toggles the ON/OFF setting. If ON or OFF is

specified, SUnique is set to that value, regardless of its current
setting. The 
NAME/NONAME setting can be changed as SUniq

Re: VIPADEFINE - VIPADISTRIBUTE - VIPABACKUP - SysplexDistributor

[Ralf Berten]

Chris

Thanks for your information. After reading it seems to be a little bit clearer.
I didn't know that relation between vipadefine and vipabackup in that way you 
described. So it's ok with the definition of vipabackup in my second system. 

After reading again the definitions in the original manual it seems to be that 
my 
understanding of the vipadistribute in relation to the port was not absolutely 
correct. I can omit the port on vipadistribut and it is still possible to use 
that 
vipa with a specific port. And thats the explanaition why in my DR test (i did 
it 
with a complete shut down sysplex) everything worked even i had no 
vipadistribute-statement on lpar 2.

So thanks again and regards
Ralf

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

Re: FTP PUT with Store Unique

[P S]

On Mon, Nov 2, 2009 at 10:05 AM, Miller, Pat wrote:

> It would appear that some of the application programmers whom I've been
> admonishing to be more explicit than "A processing error has occurred"
> have been advising the FTP developers in their considerable spare time
> on how to handle error conditions.


Indeed. I have a Windows freeware app I use that falls over about once a
quarter; when it does, it puts up a dialog that says "Something bad
happened!". In this case, since it's freeware and it's rare and there's
nothing lost (I just restart it), that dialog is sufficient. And it actually
makes me smile. Not so with things like Office components failing with
useless errors!

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

Re: TRSMAIN and abendb37-4 on temporary dataset

[Field, Alan C.]

I have this note on AMATERSE:

Sometimes TRSMAIN today (Sep 2007) will fail with a space error on the

intermediate work file.

 

An unsupported undocumented option for the current TRSMAIN is adding the

TMPSPACE DD. This usually will let you terse PDSE or other things that

mess up it's calculations for work space like a large RECFM VB PDS.

 

   //TMPSPACE  DD   UNIT=SYSDA,SPACE=(CYL,(4369,1),RLSE)


Alan 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Norbert Friemel
Sent: Monday, November 02, 2009 03:35 
To: IBM-MAIN@bama.ua.edu
Subject: Re: TRSMAIN and abendb37-4 on temporary dataset

On Mon, 2 Nov 2009 11:04:22 +0200, Itschak Mugzach wrote:

>I am using TRSMAIN to unpack into a pds. The Tresed file is quit large
and
>the job abends with av37-4 on a temporary dataset that is allocated by
>TRAMAIN (DD-SYS3). Preallacting the dataset cause TRSMAIN to try to
>allocate the next dataset (and abend again). I also tried to change the
>alloc00 parmlib member and IPL again with help.
>
>How can I recover from this stupid abend?

Is your input file striped or compressed (extended format)?
http://www-01.ibm.com/support/docview.wss?uid=isg1OA22765


Norbert Friemel

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

Re: Alternatives to QuickRef?

[Dana]

On Mon, 2 Nov 2009 12:13:03 +0200, Itschak Mugzach 
 wrote:

>Does anyone knows an alternative to the mainframe product known as 
QuickRef?
>
>
>ITschak
>

Itschak,

Have  you seen IBM's 'LOOKAT' facility?

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

There's a downloadable package for running  it under TSO/E.  I've used it in 
the past when working at sites that do not have QW and it's a viable 
substitute.

Dana

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

Re: big iron mainframe vs. x86 servers

[Howard Brazee]

On Fri, 30 Oct 2009 11:24:55 -0600, Joe Pfeiffer
 wrote:

>>>Unicode has a lot of inertia at this point, and 7-bit ASCII has more.  I
>>>can reasonably expect both of them to last long after my death, and docs
>>>and conversion programs until civilization collapses to the point
>>>computers are gone.
>>
>> How about EBCDIC?

>What about it?  If I needed to read it, it would be one-line awk script
>away.  Sort of my point.

Can you reasonably expect it to last long after your death?

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

Re: big iron mainframe vs. x86 servers

[Howard Brazee]

On 31 Oct 2009 09:37:18 -0700, Patrick Scheible 
wrote:

>All the characters from the several versions of EBCDIC are in Unicode.
>It should be simple enough to map them from EBCDIC order to Unicode
>order, and back, if necessary.

Sort order would be different - will that matter?

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

Re: big iron mainframe vs. x86 servers

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Howard Brazee
> Sent: Monday, November 02, 2009 10:01 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: big iron mainframe vs. x86 servers
> 
> On 31 Oct 2009 09:37:18 -0700, Patrick Scheible 
> wrote:
> 
> >All the characters from the several versions of EBCDIC are 
> in Unicode.
> >It should be simple enough to map them from EBCDIC order to Unicode
> >order, and back, if necessary.
> 
> Sort order would be different - will that matter?

That was a BIG point that we made to the "convert to Windows!" people. The data 
in the reports would be in a different order unless they modified the SORT to 
rearrange the code points so that the ASCII would come out in EBCDIC order.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

Internal DASD and ICKDSF

[Mike Ross]

Department of dumb hobbyist questions. I have an Application Starterpak 3000 -
call it a Multiprise 2000-2xx, that's close enough for government work.

I'm blowing it out and starting afresh. I've pulled all the old 9GB internal
DASD and replaced it with shiny new (well old, new to me) 18GB DASD. I've done
the SE stuff, got it all online, mirrored pairs, formatted 3390 volumes etc. Now
I've dusted off the IBM-supplied restore tapes for the preinstalled system. 

I can't find ANY doc on restoring the preinstalled system (OS/390 2.4) from tape
(if anyone can point me to some doc specific to this preinstall it would be a
Good Thing), and it's a LONG time since I've done this. So a dumb basic question
for starters: with internal DASD, restoring a totally wiped system, do I have to
run ICKDSF first, or can I go straight to SADSS and restore the volumes?

Thanks

Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'

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

Re: Alternatives to QuickRef?

[Dave Salt]

If BookManager is available on the mainframe, a custom bookshelf can be created 
containing all of the messages and codes manuals (e.g. the ISPF messages and 
codes manual and the COBOL messages and codes manual, etc). A user then only 
has to search one bookshelf for any message or code they encounter.

 

If SimpList is available on the mainframe a user can give the bookshelf a 
label. A label is a kind of alias, and can be anything a user finds easy to 
remember (e.g. '.MSGS'). This allows the user to search the bookshelf from any 
command line anywhere in ISPF. For example, if their program just ended with 
SQL code -117 they can enter BR .MSGS -117 on the command line and this opens 
the SQL messages and codes book directly at the explanation of what -117 means.

 
Dave Salt

SimpList(tm) - try it; you'll get it! 
http://www.mackinney.com/products/program-development/simplist.html  




 
> Date: Mon, 2 Nov 2009 12:13:03 +0200
> From: imugz...@gmail.com
> Subject: Alternatives to QuickRef?
> To: IBM-MAIN@bama.ua.edu
> 
> Does anyone knows an alternative to the mainframe product known as QuickRef?
> 
> 
> ITschak
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
  
_
CDN College or University student? Get Windows 7 for only $39.99 before Jan 3! 
Buy it now!
http://go.microsoft.com/?linkid=9691636
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: An Alternative Modest PARM Proposal

[Tom Marchant]

On Sat, 31 Oct 2009 00:33:10 -0400, Robert A. Rosenberg wrote:

>At 17:40 -0500 on 10/30/2009, Paul Gilmartin wrote about Re: An
>Alternative Modest PARM Proposal:
>
>>Therefore, you should understand very well why this won't work.
>>Such utilities will misinterpret the Long Parm as a DDN override
>>list.
>
>There is NO REASON to send a Long Parm to these IBM utilities so this
>potential glitch can easily be handled by a new PARMLIB member with a
>list of programs that are NOT to be passed an extended parm (IBM
>knows who they are and the NOXPARM00 member can be supplied with the
>PTF or FUNCTION that adds PARMX Support). For ISV (and Home Grown
>RYO) utilities that accept mult-parm parmlibs, have the vendor/author
>supply the needed members to be placed into PARMLIB.
>
>Does this help?

No.  As I recall, Shmuel's original proposal was to provide a list
somewhere, preferably in PARMLIB, of programs that could not handle the long
parm.  You have added essentially the same list to is incompatible and
excessively complicated alternative.

-- 
Tom Marchant

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

Re: Internal DASD and ICKDSF

[John Eells]

Mike Ross wrote:


I can't find ANY doc on restoring the preinstalled system (OS/390 2.4) from tape
(if anyone can point me to some doc specific to this preinstall it would be a
Good Thing), and it's a LONG time since I've done this. So a dumb basic question
for starters: with internal DASD, restoring a totally wiped system, do I have to
run ICKDSF first, or can I go straight to SADSS and restore the volumes?



You need to run at least an ICKSADSF minimal INIT before using 
standalone DFSMSdss to RESTORE anything to a volume that has no volume 
label.  (This has been true since MVS/SP and is still true today.)


If I recall correctly, this requirement is documented in the DFSMSdss 
book along with the procedure for creating an IPLable copy of standalone 
DFSMSdss.  The procedure for creating the IPLable copy of ICKSADSF is in 
the DSF book.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Of interest to Developers

[Mike Ross]

On 29 Oct 2009 21:32:34 -0700, timothy.sipp...@us.ibm.com (Timothy Sipples)
wrote:

>>I've had sufficient experience with dongles to implement
>>rule 1: If your business depends on it, crack it.
>
>I disagree, and I think that's supremely bad advice. Hopefully you were
>joking.

I was not. I've known of large companies (mainly in the creative industries,
using high-end dongle protected PC-based programs, usually video
editing/animation type packages costing tens of thousands of dollars per seat)
who have had a universal policy of opening the packages, locking the dongles in
the safe, and running 'cracked' versions of the software. Nothing to do with
running more copies than licensed, everything to do with previous problems with
dongles: if you don't crack it, you don't really own or control your business -
the dongle vendor does.



>But there's an easy solution. If your business really depends on a USB key
>fob, contact the vendor and buy two, with staggered expiration dates. Put
>one at site one, the other at site two. As another option, buy one USB key
>fob, and set up a contract (with a specific Service Level Agreement) for
>authorized remote hosting as backup. Or implement a legal variation of
>these basic ideas.

Or better, the blindingly original idea that the vendor could *listen to the
customers*. Customers HATE dongles. My background includes several years working
for a company which at one time 'protected' their software with dongles. They
worked so well that from time to time the software wound up 'protected' from the
customers who had paid for it - and it was software that was pretty critical to
just-in-time production in some cases. Result? A major upgrade in the next
release, a lot of new features - and no more dongles!

>Those are much better solutions than doing something (quite frankly, at
>best) dumb, don't you think?

Bigger fish than you or me appear to have concluded otherwise. 

Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'

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

Re: Alternatives to QuickRef?

[Ron Wells]

Question... what does Lookat not do that QuickRef does ??




From:
Dana 
To:
IBM-MAIN@bama.ua.edu
Date:
11/02/2009 09:56 AM
Subject:
Re: Alternatives to QuickRef?
Sent by:
IBM Mainframe Discussion List 



On Mon, 2 Nov 2009 12:13:03 +0200, Itschak Mugzach 
 wrote:

>Does anyone knows an alternative to the mainframe product known as 
QuickRef?
>
>
>ITschak
>

Itschak,

Have  you seen IBM's 'LOOKAT' facility?

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

There's a downloadable package for running  it under TSO/E.  I've used it 
in 
the past when working at sites that do not have QW and it's a viable 
substitute.

Dana

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

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

Re: Dynamic Lnklst Changes

[Clark Morris]

On 2 Nov 2009 06:35:21 -0800, in bit.listserv.ibm-main you wrote:

>Certainly a  very strong argument against ever performing UPDATE=*.  I
>appreciate the clarification, but certainly don't like the answer.
>Without some idea about what z/OS services or subsystems might make
>unwarranted assumptions about old lnklst control structures, the user or
>other vendors are in no position to make a rational assessment about
>whether even an update on a specific running address space poses an
>imminent danger to the system.  If UPDATE can only be used when an
>unplanned IPL at some arbitrary point in the future can be tolerated,
>that would pretty well eliminate the usefulness of this option on a
>production system.  If the risk could be isolated to the updated address
>space, that might be acceptable; but if it puts arbitrary address spaces
>or the entire system at risk, that is not.
>
>From our usage of this in the past (before the risks were advertised), I
>would question the assumption that in the majority of cases it would not
>be a requirement, or at least highly useful if running address spaces
>could be updated - TSO user communities running ISPF-based applications,
>and in some cases CICS-regions come to mind.  Back before lnklst PDSEs
>were common and before we were aware of risks, we even did UPDATE=*
>several times a year to roll in revisions and free up obsolete lnklst
>datasets where the intent was definitely to affect running address
>space.  We might rename an old dataset that was removed from lnklst, but
>were careful to never delete or move such datasets until after the next
>IPL.  I guess we were just lucky, but we never saw any adverse system
>behavior from this practice.

I still remember the notifications that were sent out when the Tandem
system at the shop where I worked.  Basically they said that the
operator would do some simple procedure and that was it.  I'm not even
certain if there was an outage.
>  JC Ewing
>
>On 11/01/2009 08:13 AM, Peter Relson wrote:
>> The page-fault-driven loading case from PDSE was addressed many years ago.
>> It was not done solely for integrity reasons. It was addressed by not doing
>> page-fault-driven loading at all for LNKLST fetches.
>> 
>> The problem that will exist forever is references to the control structures
>> that will no longer be valid (or no longer be recognized as being part of a
>> LNKLST, for which special rules apply) once a LNKLST update has been made.
>> Can you guarantee, no matter how long you wait, that no address space
>> relies on those structures? Not usually. A delay makes it less likely that
>> an operation is still in progress, but by no means eliminates the
>> possibility. And these references, I believe, might not even be limited to
>> within the scope (for example) of a LOAD or similar operation, especially
>> when program objects / PDSEs are involved. That is a recollection; I don't
>> have concrete examples to share.
>> 
>> The safe thing to do is not to use UPDATE.  In the majority of cases,
>> LNKLST updates are needed only by newly started programs, not existing ones
>> (for which case no UPDATE is needed or appropriate). The rules are what the
>> rules are. They will not change. It's your system, so you can choose to
>> follow them or not at your own risk. But you should not expect subsequently
>> to be able to complain about problems that happen to arise as a result.
>> 
>>> When the changes in the
>>> link list only involve user or installation code, there is a much higher
>>> likelihood that you would understand the way the code is used and
>>> whether there are interdependencies that would be a problem
>> And in that case it is much more likely that the update is needed only by
>> programs that start (or are restarted) after this point, so no UPDATE is
>> needed.
>> 
>> FWIW, an integrity issue caused by "improper" usage by an authorized user
>> is to be dealt with by the user. The system for the most part has no
>> alternative but to do what it has been told to do, as the authorized issuer
>> could do it itself without cooperation by the operating system if it chose
>> to..
>> 
>> Peter Relson
>> z/OS Core Technology Design

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

Re: SV: An Alternative Modest PARM Proposal

[Paul Gilmartin]

On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:

>If the current JCL PARM format change from HW + 0-100 bytes
>to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
>are there any backward compatibility problems ?
>
There would be a lateral compatibility problem, in that the
parm passed from JCL would have a format different from the
parm passed by other languages, thereby violating one of
the oldest conventions of OS/360.

Put the length of the parm, whatever length, in the HW.  It's
how all languages that support long parms now do it.

-- gil

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

Re: An Alternative Modest PARM Proposal

[Binyamin Dissen]

On Mon, 2 Nov 2009 10:50:06 -0600 Paul Gilmartin  wrote:

:>On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:

:>>If the current JCL PARM format change from HW + 0-100 bytes
:>>to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
:>>are there any backward compatibility problems ?

:>There would be a lateral compatibility problem, in that the
:>parm passed from JCL would have a format different from the
:>parm passed by other languages, thereby violating one of
:>the oldest conventions of OS/360.

Huh?

:>Put the length of the parm, whatever length, in the HW.  It's
:>how all languages that support long parms now do it.

The suffix does not violate compatibility. A CVT bit could indicate the
support for the suffix.

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: Alternatives to QuickRef?

[Ted MacNEIL]

>Have  you seen IBM's 'LOOKAT' facility?

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

>There's a downloadable package for running  it under TSO/E.  I've used it in 
the past when working at sites that do not have QW and it's a viable 
substitute.

Only for IBM products.
Unless things have changed, it doesn't do ISV messages.
-
Too busy driving to stop for gas!

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

Re: Internal DASD and ICKDSF

[Mike Ross]

On 2 Nov 2009 08:37:54 -0800, in bit.listserv.ibm-main you wrote:

>Mike Ross wrote:
>
>> I can't find ANY doc on restoring the preinstalled system (OS/390 2.4) from 
>> tape
>> (if anyone can point me to some doc specific to this preinstall it would be a
>> Good Thing), and it's a LONG time since I've done this. So a dumb basic 
>> question
>> for starters: with internal DASD, restoring a totally wiped system, do I 
>> have to
>> run ICKDSF first, or can I go straight to SADSS and restore the volumes?
>
>
>You need to run at least an ICKSADSF minimal INIT before using 
>standalone DFSMSdss to RESTORE anything to a volume that has no volume 
>label.  (This has been true since MVS/SP and is still true today.)
>
>If I recall correctly, this requirement is documented in the DFSMSdss 
>book along with the procedure for creating an IPLable copy of standalone 
>DFSMSdss.  The procedure for creating the IPLable copy of ICKSADSF is in 
>the DSF book.

Thanks John, I was pretty sure I'd run ICKDSF last time I did this - I remember
it doing one volume at a time and doing it slowly! I have the original IBM
tapes that came with the system - standalone IPLable ICKDSF and SADSS tapes, and
all the volumes of the system - so I'll just hack my way through. I'll come back
if I get stuck!

Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'

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

Re: FTP PUT with Store Unique

[Chris Mason]

Pat

What you may be suffering from is an expectation that IBM documentation is 
going to be comprehensive when it comes to matters "IP and related 
protocols". It isn't and the folk behind IBM's software in the realm of "IP and 
related protocols" have never considered that they should offer a 
comprehensive description. I know because I had some acrimonious 
discussions with TCP/IP for MVS (or maybe the original VM) developers in the 
early '90s. "Hey, we just follow common practice in these matters." 
summarises the attitude to which one could add an unspoken subtext "It 
doesn't have to be the cleverest way of doing it!"

In chasing this topic up which I didn't really know before - or I did a bit 
many 
years ago but had totally forgotten - I appreciated that the STOU command is 
covered by the FTP RFC but the command which selects it, SUNIQUE by 
convention, is not. And I think - unless corrected - that "by convention" 
covers the point I want to make which is that the FTP client commands are 
just that: a convention established presumably in traditional UNIX 
implementations.

Nevertheless, if the STOU command is documented in the RFC as not having a 
name string, the corresponding RFC-complying PUT or MPUT commands just 
cannot offer "foreign host" name strings. An SUNIQUE command compatible 
with an RFC-compliant FTP client implementation has no business suggesting 
that a name can accompany the STOU command.

Incidentally, knowing that the usual FTP client line commands are just 
that, "the usual", means that the FileZilla client which I use on my PC and 
which doesn't offer the line commands - as far as I can easily see - can stand 
proudly as being as much an FTP client implementation as the traditional FTP 
clients with the usual line commands.

As for your considering that there should be an implementation which 
behaves - how? Let us assume it is as I suggested it might which is to create 
the file and "store" the contents if it did not exist already but refuse to 
create 
the file if it did exist already. Does anyone know if that is the, for example, 
SUN FTP server behaviour?

If that is what you want and thought you might be getting - and your 
suggestion of including a time stamp in the file name suggests it is - you need 
to make your views known in whatever forum represents FTP users. I'm sorry I 
can't help there but perhaps someone - still! - reading this can help.

-

The original SUNIQUE, as I find it documented in my presentation notes for 
TCP/IP for MVS V3R1 dating from 1995, had no parameters and 
simply "toggled" the setting, that is, caused STOR to be used or caused STOU 
to be used for the traditional PUT/MPUT. This tends to presuppose that a 
human is in charge able to respond to what is returned as the current setting -
 although not absolutely, since a batch file usage of the FTP client commands 
could be aware that the initial setting was OFF and the batch file - if used 
from the beginning of the FTP session - would remain in charge of whether the 
setting was ON or OFF.

In order not to be quite so limited, I can see why IBM introduced the ON and 
OFF parameters.

Obviously, if STOU is used, it becomes vital to review the output from an FTP 
client session possibly run in batch in order to know what has been created as 
the file name. It may be this inconvenience that caused some FTP server 
implementations to offer the possibility to allow a file name to be proposed. 
If 
the FTP client session is being run in batch, this presupposes that the 
typically interpretive command language supporting the batch FTP client 
session can respond to the assumed rejected PUT command when there is a 
clash of names.

Since this is non-standard and - for me anyhow - undocumented territory, I 
can only speculate.

-

As regards whether or not the error message was appropriate: knowing what 
you do now regarding the applicable RFC and allowing the Windows FTP 
developers to (pretend to) be ignorant of the non-compliant STOU "name 
extension", the error message was quite correct - except that it just might 
have said that the STOU command didn't allow any parameters rather than 
saying a trifle cryptically that the number of parameters was incorrect - but 
programmers do generalise like that, don't they?!

Chris Mason

On Mon, 2 Nov 2009 09:05:44 -0600, Miller, Pat 
 wrote:

>Thank you, Bill and Chris, for explaining the not-...@#$%ing-obvious. It
>would appear that some of the application programmers whom I've been
>admonishing to be more explicit than "A processing error has occurred"
>have been advising the FTP developers in their considerable spare time
>on how to handle error conditions.  I'll whip up a little REXX to insert
>a date/time stamp into the name before the FTP step.
>
>I foolishly assumed when I saw the SUnique parameter that - of course! -
>this was a need that many people must have and a way to handle it is
>right there in the standard FTP functionality. But apparentl

SV: SV: An Alternative Modest PARM Proposal

[Thomas Berg]

But obviously not a *backward* compatibility problem ?
And the main problem here, as I have understood the 
discussion, is the limit of 100 bytes through JCL PARM.
And that is sort of "another format" as I see it.

As the problem is (old?) programs that cannot cope with 
longer parms than 100 bytes, among them IBM module apparently, 
that's the problem that needs to be solved. 
So we cannot avoid a somewhat ugly change of the JCL PARM 
format.
 

Regards, 
Thomas Berg 
__ 
Thomas Berg   Specialist   IT-U   SWEDBANK 

 

 

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin
> Skickat: den 2 november 2009 17:50
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: SV: An Alternative Modest PARM Proposal
> 
> On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:
> 
> >If the current JCL PARM format change from HW + 0-100 bytes 
> to HW + 100 
> >bytes + FW for the new long parm + 0-??? bytes long parm, 
> are there any 
> >backward compatibility problems ?
> >
> There would be a lateral compatibility problem, in that the 
> parm passed from JCL would have a format different from the 
> parm passed by other languages, thereby violating one of the 
> oldest conventions of OS/360.
> 
> Put the length of the parm, whatever length, in the HW.  It's 
> how all languages that support long parms now do it.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 
> instructions, send email to lists...@bama.ua.edu with the 
> message: GET IBM-MAIN INFO Search the archives at 
> http://bama.ua.edu/archives/ibm-main.html
> 

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

Re: Alternatives to QuickRef?

[Ted MacNEIL]

>Question... what does Lookat not do that QuickRef does ??

Other vendor's messages, for one.
-
Too busy driving to stop for gas!

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

Re: big iron mainframe vs. x86 servers

[Howard Brazee]

On Mon, 02 Nov 2009 09:45:34 -0700, Joe Pfeiffer
 wrote:

>Unicode has a lot of inertia at this point, and 7-bit ASCII has more.  I
>can reasonably expect both of them to last long after my death, and docs
>and conversion programs until civilization collapses to the point
>computers are gone.

 How about EBCDIC?
>>
>>>What about it?  If I needed to read it, it would be one-line awk script
>>>away.  Sort of my point.
>>
>> Can you reasonably expect it to last long after your death?
>
>I'm not quite sure whether you mean EBCDIC or the awk script; if EBCDIC
>yes, the awk script has never needed to be written, so unless I come
>across some reason to read some EBCDIC, no.

You were talking about Unicode and 7-bit ASCII lasting long after your
death.   I just extended this to ask your opinion about a more
on-topic coding system in ibm-main.

I wouldn't be surprised if IBM wouldn't be quite satisfied switching
away from MVS/EBCDIC.

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

Re: big iron mainframe vs. x86 servers

[Howard Brazee]

On 02 Nov 2009 09:08:18 -0800, Patrick Scheible 
wrote:

>> Sort order would be different - will that matter?
>
>Yes, there are probably some programs for which it does.  Those that
>do will have to convert Unicode to EBCDIC and probably convert back
>again to do their final output.  Or be rewritten completely.

I have modified programs when our IBM mainframe shop moved from DOS to
OS and the default sign in unsigned numbers changed, so that comparing
old data still worked.

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

Re: SV: SV: An Alternative Modest PARM Proposal

[Howard Brazee]

On 2 Nov 2009 09:19:45 -0800, thomas.b...@swedbank.se (Thomas Berg)
wrote:

>As the problem is (old?) programs that cannot cope with 
>longer parms than 100 bytes, among them IBM module apparently, 
>that's the problem that needs to be solved. 
>So we cannot avoid a somewhat ugly change of the JCL PARM 
>format.

The well-written old programs looked at the size byte, and believed
it.

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

Re: An Alternative Modest PARM Proposal

[Tom Marchant]

On Mon, 2 Nov 2009 18:59:19 +0200, Binyamin Dissen wrote:

>On Mon, 2 Nov 2009 10:50:06 -0600 Paul Gilmartin  wrote:
>
>:>On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:
>
>:>>If the current JCL PARM format change from HW + 0-100 bytes
>:>>to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
>:>>are there any backward compatibility problems ?
>
>:>There would be a lateral compatibility problem, in that the
>:>parm passed from JCL would have a format different from the
>:>parm passed by other languages, thereby violating one of
>:>the oldest conventions of OS/360.
>
>Huh?
>
>:>Put the length of the parm, whatever length, in the HW.  It's
>:>how all languages that support long parms now do it.
>
>The suffix does not violate compatibility. A CVT bit could indicate the
>support for the suffix.

So that a program that works with a long parm today, such as the Assembler,
would have to be modified to test the CVT and look in a new place for the
long parm.  A poor solution, IMO.

-- 
Tom Marchant

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

Re: SV: An Alternative Modest PARM Proposal

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Thomas Berg
> Sent: Monday, November 02, 2009 11:15 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: SV: SV: An Alternative Modest PARM Proposal
> 
> But obviously not a *backward* compatibility problem ?
> And the main problem here, as I have understood the 
> discussion, is the limit of 100 bytes through JCL PARM.
> And that is sort of "another format" as I see it.
> 
> As the problem is (old?) programs that cannot cope with 
> longer parms than 100 bytes, among them IBM module apparently, 
> that's the problem that needs to be solved. 
> So we cannot avoid a somewhat ugly change of the JCL PARM 
> format.
>  
> 
> Regards, 
> Thomas Berg 

How about just agreeing that the HW pointed to my R1 can range in value from 0 
to +32,767. And, in the new JCL PARMX parameter which allows a PARM > 100 
bytes, put in a note such as: "Use of PARMX may or may not cause an application 
error if the number of bytes specified is greater than 100 when used with old 
code which makes assumptions about the maximum length of the PARM value." I.e.: 
USE AT YOUR OWN RISK. It is the user's responsibility to make sure that the 
programmer was not a dip. (or something to that effect).

?
--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

How to determine number of back end tapes in a B20

[Lizette Koehler]

Okay, I have been reading the manuals and still cannot find the right info.

I have a VTS which is hooked up to my Specialist.  In that guy I have backend 
tapes for the B20.

Where can I go to see HOW MANY backend tapes I have used?  And how many I have 
not used.

Is there a way from the z/OS console to do this or do I have to go to the pc?

Thanks.

Lizette

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

Re: SV: SV: An Alternative Modest PARM Proposal

[Tom Marchant]

On Mon, 2 Nov 2009 18:14:38 +0100, Thomas Berg wrote:

>But obviously not a *backward* compatibility problem ?
>And the main problem here, as I have understood the
>discussion, is the limit of 100 bytes through JCL PARM.
>And that is sort of "another format" as I see it.
>
>As the problem is (old?) programs that cannot cope with
>longer parms than 100 bytes, among them IBM module apparently,
>that's the problem that needs to be solved.
>So we cannot avoid a somewhat ugly change of the JCL PARM
>format.

There are two problems.

1.  PARM on the EXEC statement can not be over 100 characters.
2.  Some programs behave poorly and will have problems with a PARM longer
than 100 bytes.

In attempting to solve these problems, we should consider that some programs
work just fine with longer PARMs in the same format as provided by JCL.  We
should not break these programs.

-- 
Tom Marchant

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

Re: How to determine number of back end tapes in a B20

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler
> Sent: Monday, November 02, 2009 11:42 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: How to determine number of back end tapes in a B20
> 
> Okay, I have been reading the manuals and still cannot find 
> the right info.
> 
> I have a VTS which is hooked up to my Specialist.  In that 
> guy I have backend tapes for the B20.
> 
> Where can I go to see HOW MANY backend tapes I have used?  
> And how many I have not used.
> 
> Is there a way from the z/OS console to do this or do I have 
> to go to the pc?
> 
> Thanks.
> 
> Lizette

D SMS,LIB(...),DETAIL

CBR1110I OAM library status: 754
TAPE  LIB  DEVICETOT  ONL  AVL  TOTAL  EMPTY SCRTCH  ON OP
LIBRARY   TYP  TYPE  DRV  DRV  DRV  SLOTS  SLOTS   VOLS
$VTS0002  VL   3584-L22   64   64   62800205  20570  Y  Y
--
MEDIA   SCRATCH   SCRATCH   SCRATCH
TYPE  COUNT THRESHOLD  CATEGORY
MEDIA220570   400  0002
--
LIBRARY ID: B1589
OPERATIONAL STATE:  AUTOMATED
ERROR CATEGORY SCRATCH COUNT:  90
SCRATCH STACKED VOLUME COUNT:  32
PRIVATE STACKED VOLUME COUNT: 390
--
Library supports outboard policy management.
Bulk input/output not configured.


There a 390 backstore tapes, of which 32 are totally empty. Therefore 390-32 or 
358 are in-use to some degree or another.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

SV: SV: SV: An Alternative Modest PARM Proposal

[Thomas Berg]

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] För Tom Marchant
> Skickat: den 2 november 2009 18:42
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: SV: SV: An Alternative Modest PARM Proposal
> 
> On Mon, 2 Nov 2009 18:14:38 +0100, Thomas Berg wrote:
> 
> >But obviously not a *backward* compatibility problem ?
> >And the main problem here, as I have understood the 
> discussion, is the 
> >limit of 100 bytes through JCL PARM.
> >And that is sort of "another format" as I see it.
> >
> >As the problem is (old?) programs that cannot cope with longer parms 
> >than 100 bytes, among them IBM module apparently, that's the problem 
> >that needs to be solved.
> >So we cannot avoid a somewhat ugly change of the JCL PARM format.
> 
> There are two problems.
> 
> 1.  PARM on the EXEC statement can not be over 100 characters.

Well, the idea was to change exactly that...

> 2.  Some programs behave poorly and will have problems with a 
> PARM longer than 100 bytes.

..And the idea was also to solve that problem... :)

> 
> In attempting to solve these problems, we should consider 
> that some programs work just fine with longer PARMs in the 
> same format as provided by JCL.  We should not break these programs.
> 
> --
> Tom Marchant
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 
> instructions, send email to lists...@bama.ua.edu with the 
> message: GET IBM-MAIN INFO Search the archives at 
> http://bama.ua.edu/archives/ibm-main.html

 

Regards, 
Thomas Berg 
__ 
Thomas Berg   Specialist   IT-U   SWEDBANK 


> 

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

Re: Alternatives to QuickRef?

[Dana]

Yes, other vendor's messages for one.I should have added a disclaimer to 
my statement about that.Another is that QW can dispense lots of other 
goodies such as utility control statement formats,  commands,  REXX and clist  
etc.   And it handles multiple releases of info much better than Lookat.

Dana

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

SV: SV: An Alternative Modest PARM Proposal

[Thomas Berg]

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] För McKown, John
> Skickat: den 2 november 2009 18:38
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: SV: An Alternative Modest PARM Proposal
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Thomas Berg
> > Sent: Monday, November 02, 2009 11:15 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: SV: SV: An Alternative Modest PARM Proposal
> > 
> > But obviously not a *backward* compatibility problem ?
> > And the main problem here, as I have understood the 
> discussion, is the 
> > limit of 100 bytes through JCL PARM.
> > And that is sort of "another format" as I see it.
> > 
> > As the problem is (old?) programs that cannot cope with 
> longer parms 
> > than 100 bytes, among them IBM module apparently, that's 
> the problem 
> > that needs to be solved.
> > So we cannot avoid a somewhat ugly change of the JCL PARM format.
> >  
> > 
> > Regards,
> > Thomas Berg
> 
> How about just agreeing that the HW pointed to my R1 can 
> range in value from 0 to +32,767. And, in the new JCL PARMX 
> parameter which allows a PARM > 100 bytes, put in a note such 
> as: "Use of PARMX may or may not cause an application error 
> if the number of bytes specified is greater than 100 when 
> used with old code which makes assumptions about the maximum 
> length of the PARM value." I.e.: USE AT YOUR OWN RISK. It is 
> the user's responsibility to make sure that the programmer 
> was not a dip. (or something to that effect).
> 
> ?

Don't we then have a usage problem here ?  I'm thinking of thousands 
of sites with many more programmers and operators etc. that have 
to deal with - now - two forms of parms.  I'm thinking of some sort of caos...
And don't we still have the problem of powerful system modules that 
(although somewhat wrongly) depends on JCL parm never having more 
that 100 bytes ?   (Will PARMX appear as an ordinarie parm to the 
receiving program ?)



Regards, 
Thomas Berg 
__ 
Thomas Berg   Specialist   IT-U   SWEDBANK 

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

Re: SV: An Alternative Modest PARM Proposal

[Paul Gilmartin]

On Mon, 2 Nov 2009 11:38:25 -0600, McKown, John wrote:
>
>How about just agreeing that the HW pointed to my R1 can range in value from 0 
>to +32,767.
>
In fact, at least one IBM program (I just tested it) works quite well with
a PARM string length of 65,635 in the HW.

>And, in the new JCL PARMX parameter which allows a PARM > 100 bytes, put in a 
>note such as: "Use of PARMX may or may not cause an application error if the 
>number of bytes specified is greater than 100 when used with old code which 
>makes assumptions about the maximum length of the PARM value." I.e.: USE AT 
>YOUR OWN RISK. It is the user's responsibility to make sure that the 
>programmer was not a dip. (or something to that effect).
>
The possible value of the new keyword (PARMX? EPARM? whatever) is that it
allows such a warning in the doc and allows JCL that inadvertently uses a
PARM>100 (perhaps by unexpected symbol substitution) to continue to fail
with an error message as it has in the past.  Further, as John Eells
discovered with some quick research, there is some hazard of calling
AC=1 programs with unexpectedly long PARMs.  There could be a rule
enforced that when PARMX is specified, programs will always be invoked
unauthorized.

-- gil

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

Re: How to determine number of back end tapes in a B20

[Campbell Jay]

 
D SMS,LIB(libname),DETAIL

CBR1110I OAM LIBRARY STATUS: 153
TAPE  LIB  DEVICETOT  ONL  AVL  TOTAL  EMPTY SCRTCH  ON OP
LIBRARY   TYP  TYPE  DRV  DRV  DRV  SLOTS  SLOTS   VOLS
IBMVTS41  VL   3494-L10  128  128  127   4166  6  24291  Y  Y
---
MEDIA   SCRATCH   SCRATCH   SCRATCH
TYPE  COUNT THRESHOLD  CATEGORY
MEDIA111600 0  0001
MEDIA212691   200  0002
---
LIBRARY ID: 71798
OPERATIONAL STATE:  AUTOMATED
ERROR CATEGORY SCRATCH COUNT: 172
SCRATCH STACKED VOLUME COUNT: 726
PRIVATE STACKED VOLUME COUNT: 880
---
BULK INPUT/OUTPUT NOT CONFIGURED.


Jay Campbell
IBM OS Support Section


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Lizette Koehler
Sent: Monday, November 02, 2009 12:42 PM
To: IBM-MAIN@bama.ua.edu
Subject: How to determine number of back end tapes in a B20

Okay, I have been reading the manuals and still cannot find the right
info.

I have a VTS which is hooked up to my Specialist.  In that guy I have
backend tapes for the B20.

Where can I go to see HOW MANY backend tapes I have used?  And how many
I have not used.

Is there a way from the z/OS console to do this or do I have to go to
the pc?

Thanks.

Lizette

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

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

Re: An Alternative Modest PARM Proposal

[Paul Gilmartin]

On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote:
>
>Don't we then have a usage problem here ?  I'm thinking of thousands
>of sites with many more programmers and operators etc. that have
>to deal with - now - two forms of parms.  I'm thinking of some sort of caos...
>And don't we still have the problem of powerful system modules that
>(although somewhat wrongly) depends on JCL parm never having more
>that 100 bytes ?   ...
>
Today, any programmer can invoke such "powerful system modules" from
Assembler, Rexx, or several other languages with a long PARM (or
a short PARM.  Simply, they will execute unauthorized (unless the
caller was authorized).  If the rule were that specifying PARMX
caused the PGM always to be run unauthorized, the hazard would be
removed.
>
>  ...  (Will PARMX appear as an ordinarie parm to the
>receiving program ?)
>
I would hope so, to avoid the chaos you fear.  (Operators shouldn't
be concerned with PARM.  Perhaps production supervisors.)

-- gil

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

SV: An Alternative Modest PARM Proposal

[Thomas Berg]

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin
> Skickat: den 2 november 2009 19:23
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: An Alternative Modest PARM Proposal
> 
> On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote:
> >
> >Don't we then have a usage problem here ?  I'm thinking of 
> thousands of 
> >sites with many more programmers and operators etc. that 
> have to deal 
> >with - now - two forms of parms.  I'm thinking of some sort 
> of caos...
> >And don't we still have the problem of powerful system modules that 
> >(although somewhat wrongly) depends on JCL parm never having more
> >that 100 bytes ?   ...
> >
> Today, any programmer can invoke such "powerful system 
> modules" from Assembler, Rexx, or several other languages 
> with a long PARM (or a short PARM.  Simply, they will execute 
> unauthorized (unless the caller was authorized).  If the rule 
> were that specifying PARMX caused the PGM always to be run 
> unauthorized, the hazard would be removed.
> >
> >  ...  (Will PARMX appear as an ordinarie parm to the 
> >receiving program ?)
> >
> I would hope so, to avoid the chaos you fear.  (Operators 
> shouldn't be concerned with PARM.  Perhaps production supervisors.)
> 
> -- gil
> 

Well, the caos is not primarily feared based on "API" format.  I was thinking 
of Job JCLs that production planners, those who restart and corrects jobs, 
application programmers/designers etc; all those who deals with parms that 
have application dependant values that define and designate the workings of 
the job "webs".

Imagine that an important application job abends in the middle of the night.
The application responsible is waked by a telephone from one of the nights
operators asking for instructions.  And the instructions involve parm values...



Regards, 
Thomas Berg 
__ 
Thomas Berg   Specialist   IT-U   SWEDBANK 

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

Specific VOLCAT and Logical libraries

[Antonio Cecilio]

Hello,
I've to share a TS7740 and a TS3300 with 4 lpars, 2 lpars from firm1 and other 
2 from firm2. None is sysplex. 
Virtual and native volumes volsers are different from both firms and also   
Stacked volumes are different, so different stack volume pools. 

Questions:
1) For each firm I want to differenciate virtual volsers from native volsers, 
so I 
will define specific volcats, do I also have to define a vgeneral volcat ??? 
2) In terms of SMS library definition, do I have to create 4 logical libraries 
?? A 
logical virtual library fo firm1 and one to firm2 and also a native lib. to 
firm1 
and other to firm2 ?? Both firms will share the 256 virtual drive addresses and 
also the native drives addresses.

Before you tell me to RFTM, I already took a look at IBM VE TS7740 and IBM 
TS3500 with system Z manuals.

These are newbie questions, I worked so far with STK, so if you can give me 
hint, I'll apreciate.

Many thx, A.Cecilio. 

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

Re: load modules for CICS, IMS, DB2 and TSO

[Frank Swarbrick]

>>> On 10/28/2009 at 6:44 AM, in message <4ae83c91.4080...@trainersfriend.com>,
Steve Comstock  wrote:
> Frank Swarbrick wrote:
>> By the by, I added CSSLIB some time ago, but I can't for the life of me
>> remember why.  Any idea?
> 
> These are z/OS UNIX callable services.

Turns out this is where the "name/token" service modules (IEANTRT, IEANTDL, 
IEANTCR) are.

Thanks,
Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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

Re: SV: An Alternative Modest PARM Proposal

[Paul Gilmartin]

On Mon, 2 Nov 2009 19:45:43 +0100, Thomas Berg wrote:
>
>Well, the caos is not primarily feared based on "API" format.  I was thinking
>of Job JCLs that production planners, those who restart and corrects jobs,
>application programmers/designers etc; all those who deals with parms that
>have application dependant values that define and designate the workings of
>the job "webs".
>
>Imagine that an important application job abends in the middle of the night.
>The application responsible is waked by a telephone from one of the nights
>operators asking for instructions.  And the instructions involve parm values...
>
That's the lesser hazard.  The greater is that the job runs with
a truncated PARM and yields incorrect results, possibly undetected.
For that reason, PARMX is probably a good idea.  Jobs that have
not been tested with long parm can continue to use PARM and produce
JCL errors, readily diagonsed, with oversize values.

I might even advocate a new JCL command, "//L EXECU PGM=...",
where EXECU invokes the program in the unauthorized state
with long PARM allowed.  EXEC would continue to operate as
it does, respecting the AC= attribute and limiting the PARM
to 100 characters.

-- gil

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

Re: SV: An Alternative Modest PARM Proposal

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Monday, November 02, 2009 1:56 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: SV: An Alternative Modest PARM Proposal
> 

> 
> I might even advocate a new JCL command, "//L EXECU PGM=...",
> where EXECU invokes the program in the unauthorized state
> with long PARM allowed.  EXEC would continue to operate as
> it does, respecting the AC= attribute and limiting the PARM
> to 100 characters.
> 
> -- gil

Why bother with EXECU? Just STEPLIB in that step with an empty load library 
which is not APF authorized. IIRC, that will unAPF the program even if it comes 
from LPA or the linklist.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

Re: An Alternative Modest PARM Proposal

[Clark Morris]

On 2 Nov 2009 10:23:59 -0800, in bit.listserv.ibm-main you wrote:

>On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote:
>>
>>Don't we then have a usage problem here ?  I'm thinking of thousands
>>of sites with many more programmers and operators etc. that have
>>to deal with - now - two forms of parms.  I'm thinking of some sort of caos...
>>And don't we still have the problem of powerful system modules that
>>(although somewhat wrongly) depends on JCL parm never having more
>>that 100 bytes ?   ...
>>
>Today, any programmer can invoke such "powerful system modules" from
>Assembler, Rexx, or several other languages with a long PARM (or
>a short PARM.  Simply, they will execute unauthorized (unless the
>caller was authorized).  If the rule were that specifying PARMX
>caused the PGM always to be run unauthorized, the hazard would be
>removed.
>>
>>  ...  (Will PARMX appear as an ordinarie parm to the
>>receiving program ?)
>>
>I would hope so, to avoid the chaos you fear.  (Operators shouldn't
>be concerned with PARM.  Perhaps production supervisors.)

Any authorized program that didn't verify that the parm length was 
acceptable was poorly coded.  I know that my programs checked for
maximum value and also minimum values so that I knew that the program
didn't pick up garbage.  
>
>-- gil
>

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

SV: SV: An Alternative Modest PARM Proposal

[Thomas Berg]

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin
> Skickat: den 2 november 2009 20:56
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: SV: An Alternative Modest PARM Proposal
> 
> On Mon, 2 Nov 2009 19:45:43 +0100, Thomas Berg wrote:
> >
> >Well, the caos is not primarily feared based on "API" format.  I was 
> >thinking of Job JCLs that production planners, those who restart and 
> >corrects jobs, application programmers/designers etc; all those who 
> >deals with parms that have application dependant values that 
> define and 
> >designate the workings of the job "webs".
> >
> >Imagine that an important application job abends in the 
> middle of the night.
> >The application responsible is waked by a telephone from one of the 
> >nights operators asking for instructions.  And the 
> instructions involve parm values...
> >
> That's the lesser hazard.  The greater is that the job runs 
> with a truncated PARM and yields incorrect results, possibly 
> undetected.
> For that reason, PARMX is probably a good idea.  Jobs that 
> have not been tested with long parm can continue to use PARM 
> and produce JCL errors, readily diagonsed, with oversize values.
> 
> I might even advocate a new JCL command, "//L EXECU PGM=...", 
> where EXECU invokes the program in the unauthorized state 
> with long PARM allowed.  EXEC would continue to operate as it 
> does, respecting the AC= attribute and limiting the PARM to 
> 100 characters.
> 
> -- gil
> 

If we really go the "new syntax road", I liked the suggestion, 
by someone I don't remember for the moment, that we introduce 
a new JCL operand:
// PARM '...'
I like that partly beacuse of possibility to have a "concatenate"
function like:
// PARM 'part 1 .'
// PARM 'part 2 .'
// PARM 'part 3 .'
etc.
An easy way to input a long parm (in JCL).



*BUT*, we still we have the problem of backward incompatibility 
regardless of the input format... 

 

Regards, 
Thomas Berg 
__ 
Thomas Berg   Specialist   IT-U   SWEDBANK 

  

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

Re: SV: An Alternative Modest PARM Proposal

[Tom Marchant]

On Mon, 2 Nov 2009 14:02:26 -0600, McKown, John wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List
>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
>>
>> I might even advocate a new JCL command, "//L EXECU PGM=...",
>> where EXECU invokes the program in the unauthorized state
>> with long PARM allowed.  EXEC would continue to operate as
>> it does, respecting the AC= attribute and limiting the PARM
>> to 100 characters.
>>
>
>Why bother with EXECU? Just STEPLIB in that step with an empty 
>load library which is not APF authorized. IIRC, that will unAPF the 
>program even if it comes from LPA or the linklist.

And override any JOBLIB.

-- 
Tom Marchant

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

Re: An Alternative Modest PARM Proposal

[Rick Fochtman]

There is NO REASON to send a Long Parm to these IBM utilities
   



Of course there is. It ignores, e.g., IBM compilers.
 


-
IIRC, the IBM compilers will also accept a "*PROCESS" statement that can 
be as long as necessary.


Rick

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

Re: SV: SV: An Alternative Modest PARM Proposal

[Tom Marchant]

On Mon, 2 Nov 2009 21:16:42 +0100, Thomas Berg wrote:
>
>*BUT*, we still we have the problem of backward incompatibility
>regardless of the input format...

Not if the PARM is stored in memory the same way it is today:  A fullword
parameter address with the high order bit set to 1.  That word points to a
halfword length followed by the number of bytes specified in the halfword. 
The only difference is that the data could be more than 100 characters. 
Well designed programs, such as the Assembler, would work fine.

-- 
Tom Marchant

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

Re: An Alternative Modest PARM Proposal

[Don Williams]

I would prefer to be able to pass a long parm to authorized programs.

Authorized programs should be well written to check everything it receives,
otherwise it is a security risk. In other words, an authorized program
should always be written to prevent any detrimental activity, malicious or
otherwise. If it doesn't, I would consider it broken and in need of repair. 

However, I understand that there could be situations where it might not be
feasible to fix them. I would prefer an option to use a security
class/profile control the use of PARMX. Perhaps something like class
FACILITY profile JCL.EXEC.PARMX.program-name.

Don Williams


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Monday, November 02, 2009 1:23 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: An Alternative Modest PARM Proposal

On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote:
>
>Don't we then have a usage problem here ?  I'm thinking of thousands
>of sites with many more programmers and operators etc. that have
>to deal with - now - two forms of parms.  I'm thinking of some sort of
caos...
>And don't we still have the problem of powerful system modules that
>(although somewhat wrongly) depends on JCL parm never having more
>that 100 bytes ?   ...
>
Today, any programmer can invoke such "powerful system modules" from
Assembler, Rexx, or several other languages with a long PARM (or
a short PARM.  Simply, they will execute unauthorized (unless the
caller was authorized).  If the rule were that specifying PARMX
caused the PGM always to be run unauthorized, the hazard would be
removed.
>
>  ...  (Will PARMX appear as an ordinarie parm to the
>receiving program ?)
>
I would hope so, to avoid the chaos you fear.  (Operators shouldn't
be concerned with PARM.  Perhaps production supervisors.)

-- gil

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

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

Re: An Alternative Modest PARM Proposal

[Paul Gilmartin]

On Mon, 2 Nov 2009 21:16:42 +0100, Thomas Berg wrote:
>
>If we really go the "new syntax road", I liked the suggestion,
>by someone I don't remember for the moment, that we introduce
>a new JCL operand:
>// PARM '...'
>I like that partly beacuse of possibility to have a "concatenate"
>function like:
>// PARM 'part 1 .'
>// PARM 'part 2 .'
>// PARM 'part 3 .'
>etc.
>An easy way to input a long parm (in JCL).
>
That would be of considerable value even given the 100-character
limit.  PARM continuation is a PITA, particularly when the JCL
is being generated by a program.  OTOH, JCL symbols provide
fast symptomatic relief:  PARM='&PART1&PART2&PART3'

>*BUT*, we still we have the problem of backward incompatibility
>regardless of the input format...
>
As long as authorized programs are excluded, no new incompatibility
is introduced.  Any programmer can today call any unauthorized
program with Rexx with a 65,535 character PARM.

...
PARM = d2c( 65535 )left( 'WOMBAT', 65535 )
address ATTCHPGM 'MYPROGM PARM'
...

But that's not a solution because it's cumbersome and
doesn't support the use of JCL symbols.

Regarding John M's suggestion of using STEPLIB to suppress
execution in authorized state:

o I'm uneasy with such reliance on a side effect; it lacks
  referential transparency (not that that's ever been much
  a concern in the design of JCL).

o It leaves too great a hazard of inadvertently executing
  a program in authorized state with a long PARM, either
  - because the programmer doesn't supply a STEPLIB and
symbol substitution unexpectedly creates a long PARM
  - or because the data set the programmer supplies is
later marked authorized without consideration of the
indirect consequence.
  Tom M. has supplied an example.

Regarding Clark M's assertion:

Any authorized program that didn't verify that the parm length was
acceptable was poorly coded.  I know that my programs checked for
maximum value and also minimum values so that I knew that the program
didn't pick up garbage.

Kudos.  But even representatives of the most reputable organizations
can slip up:

   Linkname: Re: Long parms ... again (was: Reading DD card information)
URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0909&L=ibm-main&P=153276

(My apologies for misattributing this to John EElls; it was
Jim Mulder, citing a survey by Karl Schmitz.)

-- gil

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

HTTP server config question

[Jousma, David]

All,

Today, as one of the directives in httpd.conf on my 1.10 system I have:

Exec/uCMDB/*  /u/HP/Discovery/cgi-bin/*  

Directory /u/HP/Discovery/cgi-bin/ contains REXX execs that also reside
in a standard MVS PDS dataset.

Is it possible using the MVSDS service to point to the PDS directly?  If
so, can someone possibly give an example?  I'm looking at HTTP Server
Planning, Installing and Using guide, and it is not clear to me if this
would be possible.

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


This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: An Alternative Modest PARM Proposal

[Paul Gilmartin]

On Mon, 2 Nov 2009 14:47:12 -0600, Rick Fochtman wrote:

>
>
>>>There is NO REASON to send a Long Parm to these IBM utilities
>>
>>Of course there is. It ignores, e.g., IBM compilers.
>>
>-
>IIRC, the IBM compilers will also accept a "*PROCESS" statement that can
>be as long as necessary.
>
o Have you checked _all_ the compilers?  What about HLASM?

o What about ISV programs and even user programs?

o Does this support JCL symbol substitution in the body of
  the "*PROCESS" statement?  (I suspect not.)

Admitted, I've been able to pass long parms to programs from
Rexx.  And even to manufacture those parms using JCL symbols
passed in the parm to Rexx.  The "Modest Proposal" under
discussion here is to make the operation simpler.

-- gil

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

Re: An Alternative Modest PARM Proposal

[Binyamin Dissen]

On Mon, 2 Nov 2009 11:32:34 -0600 Tom Marchant 
wrote:

:>On Mon, 2 Nov 2009 18:59:19 +0200, Binyamin Dissen wrote:

:>>On Mon, 2 Nov 2009 10:50:06 -0600 Paul Gilmartin  
wrote:

:>>:>On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:

:>>:>>If the current JCL PARM format change from HW + 0-100 bytes
:>>:>>to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
:>>:>>are there any backward compatibility problems ?

:>>:>There would be a lateral compatibility problem, in that the
:>>:>parm passed from JCL would have a format different from the
:>>:>parm passed by other languages, thereby violating one of
:>>:>the oldest conventions of OS/360.

:>>Huh?

:>>:>Put the length of the parm, whatever length, in the HW.  It's
:>>:>how all languages that support long parms now do it.

:>>The suffix does not violate compatibility. A CVT bit could indicate the
:>>support for the suffix.

:>So that a program that works with a long parm today, such as the Assembler,
:>would have to be modified to test the CVT and look in a new place for the
:>long parm.  A poor solution, IMO.

Compatibility has its costs. This solution does not change the number of
parameters and is completely compatible.

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: an alternative modest PARM proposal

[john gilmore]

| Of course there is. It ignores, e.g., IBM compilers.
|
| >-
|

| IIRC, the IBM compilers will also accept a "*PROCESS"

| statement that can be as long as necessary.


You don't remember correctly.  Some process statements are limiteds to a proper 
substring of a card image.  Multiple process statements are, however, often 
supported.  Le bon Dieu est dans le détail.


John Gilmore Ashland, MA 01721-1817 USA


  
_
Hotmail: Trusted email with Microsoft's powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/
http://clk.atdmt.com/GBL/go/177141664/direct/01/

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

Re: SV: SV: An Alternative Modest PARM Proposal

[Robert A. Rosenberg]

At 18:14 +0100 on 11/02/2009, Thomas Berg wrote about SV: SV: An 
Alternative Modest PARM Proposal:



As the problem is (old?) programs that cannot cope with
longer parms than 100 bytes, among them IBM module apparently,
that's the problem that needs to be solved.


Not exactly on the IBM programs. There was a suggestion to allow a 
longer than 100 byte passed parm by changing the passed parm list 
from one entry (pointing at the current 100 byte-max JCL PARM) to a 2 
entry parm list (with parm 1 staying the same and the added parm 2 
pointing at the extended JCL PARMX [or whatever IBM wants to call it] 
contents).


The IBM Program module issue is that many of the IBM Utilities can be 
called (as opposed to JCL EXEC PGM= Launched) with a multi-entry 
Parmlist (with parms 2 and on pointing at DD Name overrides). This 
would conflict with using Parm 2 to point at a PARMX entry. The 
SIMPLE solution is to have the INIT and JCL Parsing code suppress the 
passing of a PARMX to these Utilities (IBM knows who has this 
optional parm list support and can thus build the needed suppression 
list by populating it from a PARMLIB member).


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

Re: An Alternative Modest PARM Proposal

[Robert A. Rosenberg]

At 11:26 -0600 on 11/01/2009, Rick Fochtman wrote about Re: An 
Alternative Modest PARM Proposal:



--
There is NO REASON to send a Long Parm to these IBM utilities so 
this potential glitch can easily be handled by a new PARMLIB member 
with a list of programs that are NOT to be passed an extended parm 
(IBM knows who they are and the NOXPRM00 member can be supplied with 
the PTF or FUNCTION that adds PARMX Support). For ISV (and Home 
Grown RYO) utilities that accept mult-parm parmlibs, have the 
vendor/author supply the needed members to be placed into PARMLIB.

--
Do you intend to include in that list the potentially thousands of 
application programs that might accept a parm string in any business 
shop? And parse that list at IPL time? Or at program initiation 
time? What about existing apps that nobody can even remember the 
details inside?


Why not? For ISV code they just supply the needed PARMLIB member as 
they currently do. As for RYO code, the program is BAD (Broken As 
Designed) if it accepts additional parms when called as opposed to 
JCL Launched and does not validate them. Note that my comment is NOT 
about passing a longer than 100 byte parm as the ONLY entry in the 
passed Parm List but passing a 2 entry parm with the 2nd entry as the 
extended parm. The only case where there would be a conflict (and 
thus a need to suppress the passing of the PARMX) is for those 
programs ALREADY able to be passed a mult-parm parm list WHEN CALLED. 
All other programs would need to be written to look for a 2nd parm 
with an PARMX longer string.


If you have multi-parm accepting programs you are unaware of, WHY are 
you attempting to pass them a PARMX via JCL in the first place? 
Remember that you need to add the support in the first place and thus 
it is an error to just code a PARMX for a program that will not 
accept it (independent of the CALLED PARMLIST issue). You also have 
the sanity check issue I mentioned above where the PARMX attempt 
should cause the program to reject the PARMX or malfunction and this 
signal the need to fix the JCL to remove the erroneous PARMX.


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

Re: An Alternative Modest PARM Proposal

[Robert A. Rosenberg]

At 12:58 -0500 on 11/01/2009, Shmuel Metz (Seymour J.) wrote about 
Re: An Alternative Modest PARM Proposal:



 >There is NO REASON to send a Long Parm to these IBM utilities

Of course there is. It ignores, e.g., IBM compilers.


When CALLED as opposed to JCL LAUNCHED, do these IBM Compilers accept 
a longer than 100 character PARM Entry (while also accepting DDNAME 
Overrides in Parms 2+)? If so THEN you have a conflict with using a 
PARMX. If the passed PARM is still only 100 bytes even when called, 
there is no issue.


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

User

[Clayton Buck]

PW RESET
 
The information contained in this message, and any attachments thereto, 
is intended solely for the use of the addressee(s) and may contain 
confidential and/or privileged material.  Any review, retransmission, 
dissemination, copying, or other use of the transmitted information is 
prohibited.  If you received this in error, please contact the sender 
and delete the material from any computer.  UNIGROUPINC.COM 


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

User

[Clayton Buck]

pw reset

Clayton Buck
Lead System Performance/Capacity Planning  Analyst
UniGroup, Inc.

636-349-2859
 
The information contained in this message, and any attachments thereto, 
is intended solely for the use of the addressee(s) and may contain 
confidential and/or privileged material.  Any review, retransmission, 
dissemination, copying, or other use of the transmitted information is 
prohibited.  If you received this in error, please contact the sender 
and delete the material from any computer.  UNIGROUPINC.COM 


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

Outlook Reply behaviour (Example: RE: SV: SV: An Alternative Modest PARM Proposal)

[van der Grijn, Bart (B)]

My apologies if this has been discussed in the past, but as someone that
groups his IBM-Main inbox by Subject I want to point out the following: 
http://www.trilithium.com/johan/2005/06/re-outlook/

As far as I'm concerned everyone has the right to use whatever reply
prefix they want and I don't even know if Outlook is a factor in the
example I used in the subject, or even if the suggested solution works,
but I just want to point out what seems like an option that would make
the subjects more manageable.

Thanks,
Bart

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

Re: How to determine number of back end tapes in a B20

[BOB COSBY]

MVS command:  d sms,lib(vtsname),detail

CBR1110I OAM library status: 963
TAPE  LIB  DEVICETOT  ONL  AVL  TOTAL  EMPTY SCRTCH  ON OP
LIBRARY   TYP  TYPE  DRV  DRV  DRV  SLOTS  SLOTS   VOLS
STOOGES   VL   3494-L10  240  240  222   1803806  76719  Y  Y
--
MEDIA   SCRATCH   SCRATCH   SCRATCH
TYPE  COUNT THRESHOLD  CATEGORY
MEDIA15 0  0001
MEDIA276714  5000  0002
--
LIBRARY ID: B2789
OPERATIONAL STATE:  AUTOMATED
ERROR CATEGORY SCRATCH COUNT:   1
SCRATCH STACKED VOLUME COUNT: 264
PRIVATE STACKED VOLUME COUNT: 732
--
Private Stacked is used 
Scratch Stacked is ready to be used

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Lizette Koehler
Sent: Monday, November 02, 2009 11:42 AM
To: IBM-MAIN@bama.ua.edu
Subject: How to determine number of back end tapes in a B20

Okay, I have been reading the manuals and still cannot find the right
info.

I have a VTS which is hooked up to my Specialist.  In that guy I have
backend tapes for the B20.

Where can I go to see HOW MANY backend tapes I have used?  And how many
I have not used.

Is there a way from the z/OS console to do this or do I have to go to
the pc?

Thanks.

Lizette

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

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

Re: An Alternative Modest PARM Proposal

[Paul Gilmartin]

On Mon, 2 Nov 2009 16:58:37 -0500, Robert A. Rosenberg wrote:

>At 12:58 -0500 on 11/01/2009, Shmuel Metz (Seymour J.) wrote about
>Re: An Alternative Modest PARM Proposal:
>
>>  >There is NO REASON to send a Long Parm to these IBM utilities
>>
>>Of course there is. It ignores, e.g., IBM compilers.
>
>When CALLED as opposed to JCL LAUNCHED, do these IBM Compilers accept
>a longer than 100 character PARM Entry (while also accepting DDNAME
>Overrides in Parms 2+)? If so THEN you have a conflict with using a
>PARMX. If the passed PARM is still only 100 bytes even when called,
>there is no issue.
>
First, as Shmuel notes, most programs don't differentiate between
being CALLED and JCL LAUNCHED.  They're oblivious, and it's pretty
hard to tell; parameters is parameters.  If a second parameter is
present, it shall be taken as a ddnamelist.

Then, as I cited yesterday (but I also often fail to read the
preceding plies in threads):

   Linkname: Invoking the assembler dynamically
URL: 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ASMP1020/7.5

Clearly mentions that "ddnamelist" is supported, but omits mention
of a limit of length of "optionlist".  RCF submitted.

-- gil

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

Re: An Alternative Modest PARM Proposal

[Paul Gilmartin]

On Mon, 2 Nov 2009 23:50:17 +0200, Binyamin Dissen wrote:
>
>:>>The suffix does not violate compatibility. A CVT bit could indicate the
>:>>support for the suffix.
>
>:>So that a program that works with a long parm today, such as the Assembler,
>:>would have to be modified to test the CVT and look in a new place for the
>:>long parm.  A poor solution, IMO.
>
>Compatibility has its costs. This solution does not change the number of
>parameters and is completely compatible.
>
You and I have diametrically opposed perspectives of "compatibility".
To me, "compatibility" means the facility to call a program from JCL
with a long PARM presenting exactly the same interface as today when
it's called from other languages (such as Rexx), and requiring
modification neither of the target program nor of the calling language
(i.e. Rexx).  You seem to advocate that the interface when called
from JCL should differ from the interface when called from Rexx, etc.
I can't view that as "compatible".

Yes, some programs would break if they could be called from JCL
with long parms, identically as they'd break if called from Rexx,
etc. with the same parms.  Even that identical behavior in breakage
is a form of compatibility.

-- gil

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

Re: Internal DASD and ICKDSF

[Mike Ross]

On 2 Nov 2009 08:37:54 -0800, ee...@us.ibm.com (John Eells) wrote:

>Mike Ross wrote:
>
>> I can't find ANY doc on restoring the preinstalled system (OS/390 2.4) from 
>> tape
>> (if anyone can point me to some doc specific to this preinstall it would be a
>> Good Thing), and it's a LONG time since I've done this. So a dumb basic 
>> question
>> for starters: with internal DASD, restoring a totally wiped system, do I 
>> have to
>> run ICKDSF first, or can I go straight to SADSS and restore the volumes?
>
>
>You need to run at least an ICKSADSF minimal INIT before using 
>standalone DFSMSdss to RESTORE anything to a volume that has no volume 
>label.  (This has been true since MVS/SP and is still true today.)
>
>If I recall correctly, this requirement is documented in the DFSMSdss 
>book along with the procedure for creating an IPLable copy of standalone 
>DFSMSdss.  The procedure for creating the IPLable copy of ICKSADSF is in 
>the DSF book.

Well that worked. Two problems: 

1. SADSS says the 3390-2 volume I created isn't big enough to restore the system
pack (R1ASP4) - it has something like 08nn cylinders but wants 0Dnn - which
seems too much.

2. I discovered the S/390 is putting out so much interference it stops my fire
department pager from receiving calls anywhere in the house! So I think I'll put
the project on ice while I decide what to do.

Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'

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

VTAM encryption

[Munif Sadek]

Dear listers

I am interested in implementing some kind of session level encryption for SNA 
data  (LU 6.2 \ Enterprise Extender) but do not have a crypto processor.

Is it possible to do Session level encryption. IPSEC still far away for us.


regards 
Munif

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

Re: An Alternative Modest PARM Proposal

[Chris Craddock]

>
>
> >
> You and I have diametrically opposed perspectives of "compatibility".
> To me, "compatibility" means the facility to call a program from JCL
> with a long PARM presenting exactly the same interface as today when
> it's called from other languages (such as Rexx), and requiring
> modification neither of the target program nor of the calling language
> (i.e. Rexx).  You seem to advocate that the interface when called
> from JCL should differ from the interface when called from Rexx, etc.
> I can't view that as "compatible".
>
> Yes, some programs would break if they could be called from JCL
> with long parms, identically as they'd break if called from Rexx,
> etc. with the same parms.  Even that identical behavior in breakage
> is a form of compatibility.
>


The PARM interface is older than dirt and even though we can all agree with
hindsight that it was a momentously stupid design, it is nevertheless a
formal, documented interface and literally thousands of badly written
programs work correctly ONLY because the initiator is never going to give
them a parameter string of more that 100 characters. That's the one and only
interface contract. The assertion that you can find programs that behave
well when called directly with longer parameter strings is also true, but
completely uninteresting.

Changing the behavior of PARM is fraught with incompatibilities. So much so
that wiser heads elected not to pull the trigger on it. There are lots of
ways of enabling (much longer) parameter strings but they all necessarily
involve defining some brand new and non- overlapping interface
definition. New programs written to the putative new parameter interface
spec will work correctly and completely oblivious of the old spec. And since
the existing PARM interface will remain unchanged, all old programs will
continue work as they do now, completely oblivious of any new interface.

THAT my friends is compatibility. Not elegant, not pretty, but guaranteed
compatible. Now can we all just get over this nonsense?

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

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