Re: What is a mainframe?
On Fri, 10 Jan 2020 15:25:52 -0800, Janet Sun <4jl...@gmail.com> wrote: >Hi Steve, > >Kristine Harper created that video some years ago. > >Hope you're doing well. > >-- Janet > Kristine _Bastin_ nee Harper - wife of SHARE President, Justin Bastin. Sadly (for us), she's no longer "working for a mainframe ISV." Scott Fagen 21st Century Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: Montana is retiring its mainframe | StateScoop
Yeah, this could end up being one of those "we're five years into a one-year project" things. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Friday, January 17, 2020 12:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FW: Montana is retiring its mainframe | StateScoop Yeah. but 3 apps left, over a year to go. I'd call it a definite maybe at this point. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Montana is retiring its mainframe | StateScoop
On Fri, 17 Jan 2020 11:30:58 -0800, Charles Mills wrote: >https://statescoop.com/montana-state-government-retiring-mainframe-tim-bottenfield/SighCharlesSent > from a mobile; please excuse the brevity. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Articles like these are more interesting in what they don't say than what they do say. Many of the "services" that had been provided in the past by state and local mainframes have been moved to mainframes run by the feds, just like many federal departments have "outsourced" datacenter operations to the SSA, DISA, etc. Scott Fagen 21st Century Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tape problem
Dean, In that case, it sounds like the robot "forgot" which slot a tape volume was in and then found it again. Depending on how soon together the messages came out and if you had NEVER open'ed the door and manually moved any cartridges inside the robot - I would contact IBM to find out how/why the robot lost track of which slot a tape was in. Russell -Original Message- From: Nai, Dean To: IBM-MAIN Sent: Fri, Jan 17, 2020 1:16 pm Subject: Re: Tape problem These are physical tape. No VTS. Dean Nai On 1/16/20, 8:01 PM, "IBM Mainframe Discussion List on behalf of Russell Witt" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Brian and Dean, > >Yes, you are correct. If you insert or define a new range of virtual-volumes >to the VTS; that will drive the CBRUXENT (ENTRY) exit. If you have the CA 1 >version active, that will set the ROBTY field correctly as well as telling OAM >the status of the volume (active/private or scratch). And having the ROBTY >field set correctly is VERY important to CA 1. After all, we don't want to >call the Oracle/STK exit when a tape in the IBM VTS goes scratch and we don't >want to call CA-Vtape when an Oracle/STK volume goes scratch. So, based on the >ROBTY field we will call the appropriate interface module (if there is an >appropriate interface module, not all virtual-tape solutions have one). > >The original problem that Dean had mentioned (the CBR3770I and CBR3769I >messages) however, has nothing to do with CA 1. Those messages are being >issued because OAM has somehow "lost" track of the volume and can't find it. >If it is a virtual-volume, that would be very strange. If it is a physical >volume that indicates that for some reason it isn't in the slot where OAM >thought it had put it. How far apart and in what order to you receive the >messages? If you get the CBR3770I first, and then the CBR3769I quickly after - >that would be very strange and I would recommend contacting IBM. > >Russell Witt >CA 1 Architect > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Brian Fraser >Sent: Thursday, January 16, 2020 3:12 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Tape problem > >>> you forget to update the ROBTY and VENDOR fields > >I never update those fields. >I just insert new volumes as scratch and the library takes care of everything. >Unless it's handled by the INSERT exit? > >Brian > >On Thu, 16 Jan 2020 at 15:47, Brian Westerman >wrote: > >> It's not normally a CA-1 caused problem. This is "normally" caused >> when tapes are added to the VTS and you forget to update the ROBTY and >> VENDOR fields so tht when a tape is used (and scratched) that CA-1 can >> tell the VTS and OAM that it's again available. >> >> Someone always forgets to do this at most sites when they add tapes, >> and it isn't a problem right away because it takes a while for the >> tapes to come up and be reused. >> >> Brian >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C using Z/OS macros in C macros
Check out Peter Relson’s Share presentation on Metal C , you can google it On Fri, Jan 17, 2020 at 1:51 PM Joseph Reichman wrote: > Got it > > The # operator > The # (single number sign) operator converts a parameter of a > function-like macro into a character string > literal. For example, if macro ABC is defined using the following > directive: > #define ABC(x) #x > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Seymour J Metz > Sent: Friday, January 17, 2020 1:36 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Metal C using Z/OS macros in C macros > > z/OS Version 2 Release 4 XL C/C++ Language Reference, SC14-7308-40 > > https colon // > www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc147308/$file/cbclx01_v2r4.pdf > > Chapter 17. Preprocessor directives > > P. 405 > > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Joseph Reichman > Sent: Friday, January 17, 2020 1:18 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Metal C using Z/OS macros in C macros > > The only issue I have looking in the documentation in the metal C > reference or The XL\C language reference which has some documentation on > __asm > > No where is thre a thing about # and text substitution > > > > > > > On Jan 17, 2020, at 12:48 PM, Charles Mills wrote: > > > > I am not an expert at all on C __asm and only barely something of an > > expert on C macros so I avoided wading into this one. I will say > > > > 1. What @Peter Farley says sounds right to me. > > > > 2. Keep in mind that a macro definition in C does not "do anything" > > (so to speak -- of course it does something). It just sets up future > > text substitution. So at the time you define your macro no C variables > > need exist. There are no preexisting conditions for a macro > > definition. Your macro must be a syntactically valid macro, that's > > all. Macro definition knows nothing about variable declarations -- you > > are just setting up some rules for text substitution. > > > > Then when you invoke your macro, the C preprocessor will do its text > > substitution magic. It will use your macro definition and your macro > > invocation to create some alleged C code. Somewhat later, the C > > compiler will attempt to compile that alleged C code. So if that C > > code references a variable, then yes, that variable will have to have > > been previously (earlier in the source code file) declared. Earlier as > > in before the invocation of the macro, not necessarily before the > definition of the macro. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Farley, Peter x23353 > > Sent: Friday, January 17, 2020 8:31 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Metal C using Z/OS macros in C macros > > > > The %0 and %1 are parameters to the __asm function, it will do the > > substitution of the 2nd and 3rd parameter in the __asm(...) invocation > > into the %0 and %1 spots in the 1st parameter. > > > > And I concur with your description - the *invocation* of the "SETUP(...)" > > macro will specify the variables to be used and *those* variables are > > the ones that need to be defined, "xx" and "yy" in your example. > > > > If the OP (Mr. Reichman) codes the *invocation* of the SETUP macro as > > follows: > > > > SETUP(supstate,key) > > > > Then both "supstate" and "key" must be defined C variables. > > > > The __asm function does not *define* variables, it just *uses* them. > > The variables mentioned in an __asm invocation must already be defined > > in the C code. > > > > Peter > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of retired mainframer > > Sent: Friday, January 17, 2020 11:06 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Metal C using Z/OS macros in C macros > > > > In you C code, when you "invoke" the macro, you would provide the > > values of the two macro parameters. Something like > >SETSUP(xx,yy) > > It is the xx and yy that would show up inside the two parenthetical > > expressions in the generated code. Keep in mind that a C macro > > performs simple text substitution long before the actual compilation > starts. > > > > Based on the generated code you show, you would not terminate the > > above invocation with a semicolon. > > > > I've never used __asm but is > > __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(xx), "=s"(yy) ) what you > > want the compiler to see? > > > > Are you using %0 and %1 to mean the macro parameters? That is not the > > way C macros work. > > > > It looks like there should be a line continuation back slash following > > the left brace. I don't think you want the one that follows the right > > brace since there is no following line. > > > >> -Original Message- > >> From: IBM Mainframe Discussion
Re: Rexx or similar to clone a RACF user?
Cloning a userid is a very tricky proposition. For one thing, what does 'clone' mean to the requestor? If the userids have to be functionally identical/interchangeable, a great many paths and a cross tracks have to be explored. We don't have a program product to do this either, so it's a hit or miss exercise that involves a lot of tweaking when divergences are discovered. As Joel says, preference for groups over individual permissions is highly desirable, but that may be like remodeling the barn after the horse has escaped. Again. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joel C. Ewing Sent: Friday, January 17, 2020 1:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Rexx or similar to clone a RACF user? Unless things have changed, the problem is that RACF permissions granted directly to a user to a dataset profile or other resource profile are stored as part of that resource profile, not as part of a user profile. While user attributes and group connections to a user are easy to clone just by looking at or parsing a display of the to-be-cloned user profile, unless your installation only grants permissions via groups that are then connected to users, in the worst case you are forced to examine ALL resource profiles to see which ones had permissions for the to-be-cloned user profile and grant similar permits to the new user profile. While it could be done, It was judged impractical to examine all resource-to-user permissions from the actual RACF database; so we used a standard RACF utility to dump the RACF database in a format that could then be uploaded into DB2 tables every night. The DB2 tables could be efficiently queried to find what resource permits were granted to a specific user and needed to be cloned, and we just cloned from userids that we knew hadn't been changed since the last RACF DB2 table build. We did use REXX code to do the cloning, but it used a combination of RACF commands and DB2 queries to determine what needed to be done. Our Rexx code was not completely generic, but was customized for our installation's RACF standards and conventions, which meant that some classes of resource profiles were only granted to group profiles and could be safely ignored when cloning a user as they would be covered by replicating the group connects for the user. Joel C Ewing On 1/17/20 12:25 PM, Charles Mills wrote: > X-posted RACF-L and IBM-MAIN. > > > > A Google search reveals that the question "how do I clone a user in RACF?" > has been asked before and the answer is basically "buy Vanguard, > Beta88 or zSecure." People also mentioned "you might write a Rexx script to > do this." > > > > Not having one of those proprietary products I searched the CBT tape > to see if such a Rexx script were to be found there, without success. > > > > So my question is: does anyone know of a CBT or similar tool to clone > a RACF user, or does anyone have a Rexx script that they might be willing to > share? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx or similar to clone a RACF user?
Unless things have changed, the problem is that RACF permissions granted directly to a user to a dataset profile or other resource profile are stored as part of that resource profile, not as part of a user profile. While user attributes and group connections to a user are easy to clone just by looking at or parsing a display of the to-be-cloned user profile, unless your installation only grants permissions via groups that are then connected to users, in the worst case you are forced to examine ALL resource profiles to see which ones had permissions for the to-be-cloned user profile and grant similar permits to the new user profile. While it could be done, It was judged impractical to examine all resource-to-user permissions from the actual RACF database; so we used a standard RACF utility to dump the RACF database in a format that could then be uploaded into DB2 tables every night. The DB2 tables could be efficiently queried to find what resource permits were granted to a specific user and needed to be cloned, and we just cloned from userids that we knew hadn't been changed since the last RACF DB2 table build. We did use REXX code to do the cloning, but it used a combination of RACF commands and DB2 queries to determine what needed to be done. Our Rexx code was not completely generic, but was customized for our installation's RACF standards and conventions, which meant that some classes of resource profiles were only granted to group profiles and could be safely ignored when cloning a user as they would be covered by replicating the group connects for the user. Joel C Ewing On 1/17/20 12:25 PM, Charles Mills wrote: X-posted RACF-L and IBM-MAIN. A Google search reveals that the question "how do I clone a user in RACF?" has been asked before and the answer is basically "buy Vanguard, Beta88 or zSecure." People also mentioned "you might write a Rexx script to do this." Not having one of those proprietary products I searched the CBT tape to see if such a Rexx script were to be found there, without success. So my question is: does anyone know of a CBT or similar tool to clone a RACF user, or does anyone have a Rexx script that they might be willing to share? Thanks, Charles -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: Montana is retiring its mainframe | StateScoop
Yeah. but 3 apps left, over a year to go. I'd call it a definite maybe at this point. sas On Fri, Jan 17, 2020 at 2:33 PM Charles Mills wrote: > Well, my d@mned phone made hash out of that. Trying again. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Charles Mills > Sent: Friday, January 17, 2020 11:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Montana is retiring its mainframe | StateScoop > > > https://statescoop.com/montana-state-government-retiring-mainframe-tim-bottenfield/ > > Sigh > > Charles > > Sent from a mobile; please excuse the brevity. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FW: Montana is retiring its mainframe | StateScoop
Well, my d@mned phone made hash out of that. Trying again. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, January 17, 2020 11:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Montana is retiring its mainframe | StateScoop https://statescoop.com/montana-state-government-retiring-mainframe-tim-bottenfield/ Sigh Charles Sent from a mobile; please excuse the brevity. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Montana is retiring its mainframe | StateScoop
https://statescoop.com/montana-state-government-retiring-mainframe-tim-bottenfield/SighCharlesSent from a mobile; please excuse the brevity. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Starting an application in ISPF
LIBDEF ISPLLIB serves the purpose - except when it doesn't. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lionel B Dyck Sent: Friday, January 17, 2020 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Starting an application in ISPF And you can altlib as well - sadly you can't TSOLIB within ISPF but you can dynamic steplib with Dan Dalby's Dynamic Steplib on CBT File 452 (which works with z/OS 2.4 with no problems contrary to some vendors claims). Lionel B. Dyck < Website: http://secure-web.cisco.com/15rkwwonZqrhZnp_JWZx9WXLf6Lp2dbYaky1-pvuw2ILEXta-_5pSsFvvh1lnEbHrDBptkp2jRRgamoWr7jWnxsq3tZxS8y9inL74jeWdNeuKd2gWX0xxbe9AmGC6fIazjo9WzV4qwK6iYvo6fGKsonlk9euVjtfvVYfNgXMEgBRsM8Vdp3XEb61KpniVyrYnQ-UplOeEVf19kqps3vU2SCJCC_Cue99axqLvE-Q0beLa3TUf8rA92yjF4JbdRvo80-SpygrsnvpaqKlkX_hUEGMNcz2il2Svh0EHTowMG3iaBQVfQyutgn31V-VdK_m5eJ5FeY1Tzz0AHjvEdYZke0ANv-HvObTZsuRRjnfzzv_Ue9_ho2Ow2j480FmWa96p/http%3A%2F%2Fwww.lbdsoftware.com "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Friday, January 17, 2020 12:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Starting an application in ISPF You can write a script to LIBDEF the libraries that you need and then invoke ISMF. Put the script into you command table or panel definition. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Frank Swarbrick Sent: Thursday, January 16, 2020 6:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Starting an application in ISPF I am a developer who wants to start up the ISMF application. Being a developer I don't have it as an option on any ISPF menu. Documentation states I can use "ISPSTART PGM(DGTFMD01) NEWAPPL(DGT)" from TSO. This works, but then I have only that application running, and not my other ISPF "stuff". Is there a similar command I can use to start it from within ISPF? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C using Z/OS macros in C macros
Got it
The # operator
The # (single number sign) operator converts a parameter of a function-like
macro into a character string
literal. For example, if macro ABC is defined using the following directive:
#define ABC(x) #x
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Seymour J Metz
Sent: Friday, January 17, 2020 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Metal C using Z/OS macros in C macros
z/OS Version 2 Release 4 XL C/C++ Language Reference, SC14-7308-40
https colon
//www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc147308/$file/cbclx01_v2r4.pdf
Chapter 17. Preprocessor directives
P. 405
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Joseph Reichman
Sent: Friday, January 17, 2020 1:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Metal C using Z/OS macros in C macros
The only issue I have looking in the documentation in the metal C reference or
The XL\C language reference which has some documentation on __asm
No where is thre a thing about # and text substitution
> On Jan 17, 2020, at 12:48 PM, Charles Mills wrote:
>
> I am not an expert at all on C __asm and only barely something of an
> expert on C macros so I avoided wading into this one. I will say
>
> 1. What @Peter Farley says sounds right to me.
>
> 2. Keep in mind that a macro definition in C does not "do anything"
> (so to speak -- of course it does something). It just sets up future
> text substitution. So at the time you define your macro no C variables
> need exist. There are no preexisting conditions for a macro
> definition. Your macro must be a syntactically valid macro, that's
> all. Macro definition knows nothing about variable declarations -- you
> are just setting up some rules for text substitution.
>
> Then when you invoke your macro, the C preprocessor will do its text
> substitution magic. It will use your macro definition and your macro
> invocation to create some alleged C code. Somewhat later, the C
> compiler will attempt to compile that alleged C code. So if that C
> code references a variable, then yes, that variable will have to have
> been previously (earlier in the source code file) declared. Earlier as
> in before the invocation of the macro, not necessarily before the definition
> of the macro.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Farley, Peter x23353
> Sent: Friday, January 17, 2020 8:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Metal C using Z/OS macros in C macros
>
> The %0 and %1 are parameters to the __asm function, it will do the
> substitution of the 2nd and 3rd parameter in the __asm(...) invocation
> into the %0 and %1 spots in the 1st parameter.
>
> And I concur with your description - the *invocation* of the "SETUP(...)"
> macro will specify the variables to be used and *those* variables are
> the ones that need to be defined, "xx" and "yy" in your example.
>
> If the OP (Mr. Reichman) codes the *invocation* of the SETUP macro as
> follows:
>
> SETUP(supstate,key)
>
> Then both "supstate" and "key" must be defined C variables.
>
> The __asm function does not *define* variables, it just *uses* them.
> The variables mentioned in an __asm invocation must already be defined
> in the C code.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of retired mainframer
> Sent: Friday, January 17, 2020 11:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Metal C using Z/OS macros in C macros
>
> In you C code, when you "invoke" the macro, you would provide the
> values of the two macro parameters. Something like
>SETSUP(xx,yy)
> It is the xx and yy that would show up inside the two parenthetical
> expressions in the generated code. Keep in mind that a C macro
> performs simple text substitution long before the actual compilation starts.
>
> Based on the generated code you show, you would not terminate the
> above invocation with a semicolon.
>
> I've never used __asm but is
> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(xx), "=s"(yy) ) what you
> want the compiler to see?
>
> Are you using %0 and %1 to mean the macro parameters? That is not the
> way C macros work.
>
> It looks like there should be a line continuation back slash following
> the left brace. I don't think you want the one that follows the right
> brace since there is no following line.
>
>> -Original Message-
>> From: IBM Mainframe Discussion List On
>> Behalf Of Joseph Reichman
>> Sent: Friday, January 17, 2020 5:22 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Metal C using Z/OS macros in C macros
>>
>> Just wondering if I can do something like this
>>
>> #define SETSUP(supstate,key) \
>> {
>> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(supstate), "=s"(key) ) \
>> } \
>>
>> Seems
Re: Starting an application in ISPF
And you can altlib as well - sadly you can't TSOLIB within ISPF but you can dynamic steplib with Dan Dalby's Dynamic Steplib on CBT File 452 (which works with z/OS 2.4 with no problems contrary to some vendors claims). Lionel B. Dyck < Website: http://www.lbdsoftware.com "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Friday, January 17, 2020 12:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Starting an application in ISPF You can write a script to LIBDEF the libraries that you need and then invoke ISMF. Put the script into you command table or panel definition. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Frank Swarbrick Sent: Thursday, January 16, 2020 6:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Starting an application in ISPF I am a developer who wants to start up the ISMF application. Being a developer I don't have it as an option on any ISPF menu. Documentation states I can use "ISPSTART PGM(DGTFMD01) NEWAPPL(DGT)" from TSO. This works, but then I have only that application running, and not my other ISPF "stuff". Is there a similar command I can use to start it from within ISPF? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C using Z/OS macros in C macros
z/OS Version 2 Release 4 XL C/C++ Language Reference, SC14-7308-40
https colon
//www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc147308/$file/cbclx01_v2r4.pdf
Chapter 17. Preprocessor directives
P. 405
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Joseph Reichman
Sent: Friday, January 17, 2020 1:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Metal C using Z/OS macros in C macros
The only issue I have looking in the documentation in the metal C reference or
The XL\C language reference which has some documentation on __asm
No where is thre a thing about # and text substitution
> On Jan 17, 2020, at 12:48 PM, Charles Mills wrote:
>
> I am not an expert at all on C __asm and only barely something of an expert
> on C macros so I avoided wading into this one. I will say
>
> 1. What @Peter Farley says sounds right to me.
>
> 2. Keep in mind that a macro definition in C does not "do anything" (so to
> speak -- of course it does something). It just sets up future text
> substitution. So at the time you define your macro no C variables need
> exist. There are no preexisting conditions for a macro definition. Your
> macro must be a syntactically valid macro, that's all. Macro definition
> knows nothing about variable declarations -- you are just setting up some
> rules for text substitution.
>
> Then when you invoke your macro, the C preprocessor will do its text
> substitution magic. It will use your macro definition and your macro
> invocation to create some alleged C code. Somewhat later, the C compiler
> will attempt to compile that alleged C code. So if that C code references a
> variable, then yes, that variable will have to have been previously (earlier
> in the source code file) declared. Earlier as in before the invocation of
> the macro, not necessarily before the definition of the macro.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Friday, January 17, 2020 8:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Metal C using Z/OS macros in C macros
>
> The %0 and %1 are parameters to the __asm function, it will do the
> substitution of the 2nd and 3rd parameter in the __asm(...) invocation into
> the %0 and %1 spots in the 1st parameter.
>
> And I concur with your description - the *invocation* of the "SETUP(...)"
> macro will specify the variables to be used and *those* variables are the
> ones that need to be defined, "xx" and "yy" in your example.
>
> If the OP (Mr. Reichman) codes the *invocation* of the SETUP macro as
> follows:
>
> SETUP(supstate,key)
>
> Then both "supstate" and "key" must be defined C variables.
>
> The __asm function does not *define* variables, it just *uses* them. The
> variables mentioned in an __asm invocation must already be defined in the C
> code.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> retired mainframer
> Sent: Friday, January 17, 2020 11:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Metal C using Z/OS macros in C macros
>
> In you C code, when you "invoke" the macro, you would provide the values of
> the two macro parameters. Something like
>SETSUP(xx,yy)
> It is the xx and yy that would show up inside the two parenthetical
> expressions in the generated code. Keep in mind that a C macro performs
> simple text substitution long before the actual compilation starts.
>
> Based on the generated code you show, you would not terminate the above
> invocation with a semicolon.
>
> I've never used __asm but is
> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(xx), "=s"(yy) ) what you want
> the compiler to see?
>
> Are you using %0 and %1 to mean the macro parameters? That is not the way C
> macros work.
>
> It looks like there should be a line continuation back slash following the
> left brace. I don't think you want the one that follows the right brace
> since there is no following line.
>
>> -Original Message-
>> From: IBM Mainframe Discussion List On
>> Behalf Of Joseph Reichman
>> Sent: Friday, January 17, 2020 5:22 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Metal C using Z/OS macros in C macros
>>
>> Just wondering if I can do something like this
>>
>> #define SETSUP(supstate,key) \
>> {
>> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(supstate), "=s"(key) ) \
>> } \
>>
>> Seems like the variables have to be defined
>
> --
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly
Re: Starting an application in ISPF
You can write a script to LIBDEF the libraries that you need and then invoke ISMF. Put the script into you command table or panel definition. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Frank Swarbrick Sent: Thursday, January 16, 2020 6:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Starting an application in ISPF I am a developer who wants to start up the ISMF application. Being a developer I don't have it as an option on any ISPF menu. Documentation states I can use "ISPSTART PGM(DGTFMD01) NEWAPPL(DGT)" from TSO. This works, but then I have only that application running, and not my other ISPF "stuff". Is there a similar command I can use to start it from within ISPF? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Rexx or similar to clone a RACF user?
X-posted RACF-L and IBM-MAIN. A Google search reveals that the question "how do I clone a user in RACF?" has been asked before and the answer is basically "buy Vanguard, Beta88 or zSecure." People also mentioned "you might write a Rexx script to do this." Not having one of those proprietary products I searched the CBT tape to see if such a Rexx script were to be found there, without success. So my question is: does anyone know of a CBT or similar tool to clone a RACF user, or does anyone have a Rexx script that they might be willing to share? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Starting an application in ISPF
You can LIBDEF almost everything.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Frank Swarbrick
Sent: Thursday, January 16, 2020 7:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Starting an application in ISPF
"Luckily", whoever set up our system apparently included all of the allocations
in our standard logon, so I was able to follow Steve Smith's recommendation.
But your reply is certainly good reference. Thanks!
From: IBM Mainframe Discussion List on behalf of
Jesse 1 Robinson <02b46c9bbdf0-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, January 16, 2020 5:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Starting an application in ISPF
An ISPF application needs to have all related data sets allocated before the
application itself starts running. For the 'PDF' application, folks will have
all necessary ISPxLIBs allocated by logon proc or by some front-end REXX. In
our shop, applications like ISMF are considered specialized utilities that only
a handful of folks are expected to run, so it doesn't make sense for every user
to allocate libraries that will never be used. The problem with just "ISPSTART
PGM(DGTFMD01) NEWAPPL(DGT)" is that the typical user--in this case YOU--will
not have the right ISPxLIB environment. Same here, so what we do is provide
this lines on a menu that the appropriate folks have allocated:
% ISMF +ISMF%-+Invoke Space Management Functions
...
ISMF,'cmd(%ismfinit ) newappl(dgt) nocheck'
...
This menu can be in your own (pre-allocated) panel library.
REXX ISFMINIT contains this:
/* REXX */
TRACE N
PARSE ARG nextopt .
ADDRESS ISPEXEC
"LIBDEF ISPMLIB DATASET STACK ID('SYS1.DGTMLIB' 'SYS1.DFQMLIB')"
"LIBDEF ISPPLIB DATASET STACK ID('SYS1.DGTPLIB' 'SYS1.DFQPLIB')"
"LIBDEF ISPSLIB DATASET STACK ID('SYS1.DGTSLIB')"
"LIBDEF ISPTLIB DATASET STACK ID('SYS1.DGTTLIB')"
ADDRESS TSO "ALTLIB ACT APPL(CLIST) DATASET('SYS1.DGTCLIB')"
"SELECT PGM(DGTFMD01) PARM("nextopt")"
"LIBDEF ISPMLIB DATASET"
"LIBDEF ISPPLIB DATASET"
"LIBDEF ISPSLIB DATASET"
"LIBDEF ISPTLIB DATASET"
ADDRESS TSO "ALTLIB RESET"
You will need SAF READ access to the ISMF libraries, whatever they're called in
your shop.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Smith
Sent: Thursday, January 16, 2020 4:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Starting an application in ISPF
Just write and invoke a simple exec (or clist if that's your thing):
/* REXX */
ADDRESS ISPEXEC
'SELECT PGM(DGTFMD01) NEWAPPL(DGT) SCRNAME(ISMF)'
EXIT
You could also invoke it from option 7.1 (Dialog Test), but that adds some
overhead.
sas
On Thu, Jan 16, 2020 at 6:47 PM Frank Swarbrick
wrote:
> Doesn't work for me. Must not be in my "profile" or something.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C using Z/OS macros in C macros
The only issue I have looking in the documentation in the metal C reference or
The XL\C language reference which has some documentation on __asm
No where is thre a thing about # and text substitution
> On Jan 17, 2020, at 12:48 PM, Charles Mills wrote:
>
> I am not an expert at all on C __asm and only barely something of an expert
> on C macros so I avoided wading into this one. I will say
>
> 1. What @Peter Farley says sounds right to me.
>
> 2. Keep in mind that a macro definition in C does not "do anything" (so to
> speak -- of course it does something). It just sets up future text
> substitution. So at the time you define your macro no C variables need
> exist. There are no preexisting conditions for a macro definition. Your
> macro must be a syntactically valid macro, that's all. Macro definition
> knows nothing about variable declarations -- you are just setting up some
> rules for text substitution.
>
> Then when you invoke your macro, the C preprocessor will do its text
> substitution magic. It will use your macro definition and your macro
> invocation to create some alleged C code. Somewhat later, the C compiler
> will attempt to compile that alleged C code. So if that C code references a
> variable, then yes, that variable will have to have been previously (earlier
> in the source code file) declared. Earlier as in before the invocation of
> the macro, not necessarily before the definition of the macro.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Friday, January 17, 2020 8:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Metal C using Z/OS macros in C macros
>
> The %0 and %1 are parameters to the __asm function, it will do the
> substitution of the 2nd and 3rd parameter in the __asm(...) invocation into
> the %0 and %1 spots in the 1st parameter.
>
> And I concur with your description - the *invocation* of the "SETUP(...)"
> macro will specify the variables to be used and *those* variables are the
> ones that need to be defined, "xx" and "yy" in your example.
>
> If the OP (Mr. Reichman) codes the *invocation* of the SETUP macro as
> follows:
>
> SETUP(supstate,key)
>
> Then both "supstate" and "key" must be defined C variables.
>
> The __asm function does not *define* variables, it just *uses* them. The
> variables mentioned in an __asm invocation must already be defined in the C
> code.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> retired mainframer
> Sent: Friday, January 17, 2020 11:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Metal C using Z/OS macros in C macros
>
> In you C code, when you "invoke" the macro, you would provide the values of
> the two macro parameters. Something like
>SETSUP(xx,yy)
> It is the xx and yy that would show up inside the two parenthetical
> expressions in the generated code. Keep in mind that a C macro performs
> simple text substitution long before the actual compilation starts.
>
> Based on the generated code you show, you would not terminate the above
> invocation with a semicolon.
>
> I've never used __asm but is
> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(xx), "=s"(yy) ) what you want
> the compiler to see?
>
> Are you using %0 and %1 to mean the macro parameters? That is not the way C
> macros work.
>
> It looks like there should be a line continuation back slash following the
> left brace. I don't think you want the one that follows the right brace
> since there is no following line.
>
>> -Original Message-
>> From: IBM Mainframe Discussion List On
>> Behalf Of Joseph Reichman
>> Sent: Friday, January 17, 2020 5:22 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Metal C using Z/OS macros in C macros
>>
>> Just wondering if I can do something like this
>>
>> #define SETSUP(supstate,key) \
>> {
>> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(supstate), "=s"(key) ) \
>> } \
>>
>> Seems like the variables have to be defined
>
> --
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by e-mail
> and delete the message and any attachments from your system.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe /
Re: Starting an application in ISPF
What I've done is have an ISPF startup (zstart) command that dynamically adds the commands I want to the active ISPF command table. This way each user can do their own and it is easy and you don't have to 'bother' the sysprog (who may not allow the updates to the real command tables). I call it ISPFCMDS - available at http://lbdsoftware.com/ispftools.html or www.cbttape.org in file 312. Function: Add user ispf commands to an active ispf command table. It is recommended that all commands be added to the User command table if it is available. This is intended to be called from a user exec to add their own commands to the specified ispf command table. If the command to be added already exists then the existing command entry in the table will be replaced with the new command. Syntax:%ispfcmds table ispf-command-table-entry \ desc if table = * then default to (in order) User table Site table Current Applid Table or ISPCMDS if table = USER then the user table is updated if table = SITE then the site table is updated if table = ISPF then the ISPCMDS Table is updated The ispf-command-table-entry is in the format: verb trunc action \ description each separated by a space Usage: Sample usage: from an exec: "%ispfcmds * dd 0 select pgm(isrddn)" , "\ quick dd list" "%ispfcmds user dd 0 select pgm(isrddn)" "%ispfcmds * ee 0 edit dataset()" Lionel B. Dyck < Website: http://www.lbdsoftware.com "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Friday, January 17, 2020 11:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Starting an application in ISPF Apparently I knew how to do this once upon a time, but how do you close a user command table in order to allow editing of it? From: IBM Mainframe Discussion List on behalf of ITschak Mugzach Sent: Thursday, January 16, 2020 11:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Starting an application in ISPF And even simpler, add it's and select cmd options to your ispf command table. This way you can type a short name to invoke it. ITschak בתאריך יום ו׳, 17 בינו׳ 2020, 2:44, מאת Frank Swarbrick < frank.swarbr...@outlook.com>: > This works. Thanks much. > > > From: IBM Mainframe Discussion List on > behalf of Steve Smith > Sent: Thursday, January 16, 2020 5:16 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Starting an application in ISPF > > Just write and invoke a simple exec (or clist if that's your thing): > > /* REXX */ > ADDRESS ISPEXEC > 'SELECT PGM(DGTFMD01) NEWAPPL(DGT) SCRNAME(ISMF)' > EXIT > > You could also invoke it from option 7.1 (Dialog Test), but that adds > some overhead. > > sas > > > On Thu, Jan 16, 2020 at 6:47 PM Frank Swarbrick < > frank.swarbr...@outlook.com> > wrote: > > > Doesn't work for me. Must not be in my "profile" or something. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Starting an application in ISPF
Command tables are ispf appl dependent. Just define you appl on all xxxCMDS tables. ITschak בתאריך יום ו׳, 17 בינו׳ 2020, 19:37, מאת Frank Swarbrick < frank.swarbr...@outlook.com>: > Apparently I knew how to do this once upon a time, but how do you close a > user command table in order to allow editing of it? > > > From: IBM Mainframe Discussion List on behalf > of ITschak Mugzach > Sent: Thursday, January 16, 2020 11:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Starting an application in ISPF > > And even simpler, add it's and select cmd options to your ispf command > table. This way you can type a short name to invoke it. > > ITschak > > בתאריך יום ו׳, 17 בינו׳ 2020, 2:44, מאת Frank Swarbrick < > frank.swarbr...@outlook.com>: > > > This works. Thanks much. > > > > > > From: IBM Mainframe Discussion List on behalf > > of Steve Smith > > Sent: Thursday, January 16, 2020 5:16 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Starting an application in ISPF > > > > Just write and invoke a simple exec (or clist if that's your thing): > > > > /* REXX */ > > ADDRESS ISPEXEC > > 'SELECT PGM(DGTFMD01) NEWAPPL(DGT) SCRNAME(ISMF)' > > EXIT > > > > You could also invoke it from option 7.1 (Dialog Test), but that adds > some > > overhead. > > > > sas > > > > > > On Thu, Jan 16, 2020 at 6:47 PM Frank Swarbrick < > > frank.swarbr...@outlook.com> > > wrote: > > > > > Doesn't work for me. Must not be in my "profile" or something. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C using Z/OS macros in C macros
I am not an expert at all on C __asm and only barely something of an expert
on C macros so I avoided wading into this one. I will say
1. What @Peter Farley says sounds right to me.
2. Keep in mind that a macro definition in C does not "do anything" (so to
speak -- of course it does something). It just sets up future text
substitution. So at the time you define your macro no C variables need
exist. There are no preexisting conditions for a macro definition. Your
macro must be a syntactically valid macro, that's all. Macro definition
knows nothing about variable declarations -- you are just setting up some
rules for text substitution.
Then when you invoke your macro, the C preprocessor will do its text
substitution magic. It will use your macro definition and your macro
invocation to create some alleged C code. Somewhat later, the C compiler
will attempt to compile that alleged C code. So if that C code references a
variable, then yes, that variable will have to have been previously (earlier
in the source code file) declared. Earlier as in before the invocation of
the macro, not necessarily before the definition of the macro.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Friday, January 17, 2020 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Metal C using Z/OS macros in C macros
The %0 and %1 are parameters to the __asm function, it will do the
substitution of the 2nd and 3rd parameter in the __asm(...) invocation into
the %0 and %1 spots in the 1st parameter.
And I concur with your description - the *invocation* of the "SETUP(...)"
macro will specify the variables to be used and *those* variables are the
ones that need to be defined, "xx" and "yy" in your example.
If the OP (Mr. Reichman) codes the *invocation* of the SETUP macro as
follows:
SETUP(supstate,key)
Then both "supstate" and "key" must be defined C variables.
The __asm function does not *define* variables, it just *uses* them. The
variables mentioned in an __asm invocation must already be defined in the C
code.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
retired mainframer
Sent: Friday, January 17, 2020 11:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Metal C using Z/OS macros in C macros
In you C code, when you "invoke" the macro, you would provide the values of
the two macro parameters. Something like
SETSUP(xx,yy)
It is the xx and yy that would show up inside the two parenthetical
expressions in the generated code. Keep in mind that a C macro performs
simple text substitution long before the actual compilation starts.
Based on the generated code you show, you would not terminate the above
invocation with a semicolon.
I've never used __asm but is
__asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(xx), "=s"(yy) ) what you want
the compiler to see?
Are you using %0 and %1 to mean the macro parameters? That is not the way C
macros work.
It looks like there should be a line continuation back slash following the
left brace. I don't think you want the one that follows the right brace
since there is no following line.
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Joseph Reichman
> Sent: Friday, January 17, 2020 5:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Metal C using Z/OS macros in C macros
>
> Just wondering if I can do something like this
>
> #define SETSUP(supstate,key) \
> {
> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(supstate), "=s"(key) ) \
> } \
>
> Seems like the variables have to be defined
--
This message and any attachments are intended only for the use of the
addressee and may contain information that is privileged and confidential.
If the reader of the message is not the intended recipient or an authorized
representative of the intended recipient, you are hereby notified that any
dissemination of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by e-mail
and delete the message and any attachments from your system.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Starting an application in ISPF
Apparently I knew how to do this once upon a time, but how do you close a user command table in order to allow editing of it? From: IBM Mainframe Discussion List on behalf of ITschak Mugzach Sent: Thursday, January 16, 2020 11:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Starting an application in ISPF And even simpler, add it's and select cmd options to your ispf command table. This way you can type a short name to invoke it. ITschak בתאריך יום ו׳, 17 בינו׳ 2020, 2:44, מאת Frank Swarbrick < frank.swarbr...@outlook.com>: > This works. Thanks much. > > > From: IBM Mainframe Discussion List on behalf > of Steve Smith > Sent: Thursday, January 16, 2020 5:16 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Starting an application in ISPF > > Just write and invoke a simple exec (or clist if that's your thing): > > /* REXX */ > ADDRESS ISPEXEC > 'SELECT PGM(DGTFMD01) NEWAPPL(DGT) SCRNAME(ISMF)' > EXIT > > You could also invoke it from option 7.1 (Dialog Test), but that adds some > overhead. > > sas > > > On Thu, Jan 16, 2020 at 6:47 PM Frank Swarbrick < > frank.swarbr...@outlook.com> > wrote: > > > Doesn't work for me. Must not be in my "profile" or something. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Starting an application in ISPF
The challenges y'all raise are one reason for my writing the Product Launch Point (PLP) tool. You add PLP to the ISPF command table and then you have easy access to a fully dynamic ISPF menu. It supports nesting menus and every product is dynamically defined in a PLP table - all the dd's required, how it is started, an ispf applid if it needs a unique one. Then from any ispf panel just enter PLP ISMF (using ISMF as an example). And with PLP you have a default system level PLP and you can have individual levels and group levels. You can find it at http://lbdsoftware.com/ispftools.html or on the CBTTape File 312. The biggest advantage is you no longer have to manually edit/update ispf panels - it's all in a dynamic table. Lionel B. Dyck < Website: http://www.lbdsoftware.com "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Friday, January 17, 2020 11:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Starting an application in ISPF A command table entry can certainly be useful, but we hit a snag some years ago. (Have not retried the construction since.) Suppose you have a local panel reached via A --> B --> C, where panel C has the SELECT for your app, say ISMF. If you type A.B.C.ISMF your menu select will work one way. But if you are already on the C panel (A.B.C), then typing ISMF is ambiguous. Do you get your panel SELECT option, or do you get the command table entry? The two results may differ depending on how things are coded. Users may not be happy. ;-( . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of ITschak Mugzach Sent: Thursday, January 16, 2020 10:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Starting an application in ISPF And even simpler, add it's and select cmd options to your ispf command table. This way you can type a short name to invoke it. ITschak בתאריך יום ו׳, 17 בינו׳ 2020, 2:44, מאת Frank Swarbrick < frank.swarbr...@outlook.com>: > This works. Thanks much. > > > From: IBM Mainframe Discussion List on > behalf of Steve Smith > Sent: Thursday, January 16, 2020 5:16 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Starting an application in ISPF > > Just write and invoke a simple exec (or clist if that's your thing): > > /* REXX */ > ADDRESS ISPEXEC > 'SELECT PGM(DGTFMD01) NEWAPPL(DGT) SCRNAME(ISMF)' > EXIT > > You could also invoke it from option 7.1 (Dialog Test), but that adds > some overhead. > > sas > > > On Thu, Jan 16, 2020 at 6:47 PM Frank Swarbrick < > frank.swarbr...@outlook.com> > wrote: > > > Doesn't work for me. Must not be in my "profile" or something. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Starting an application in ISPF
A command table entry can certainly be useful, but we hit a snag some years ago. (Have not retried the construction since.) Suppose you have a local panel reached via A --> B --> C, where panel C has the SELECT for your app, say ISMF. If you type A.B.C.ISMF your menu select will work one way. But if you are already on the C panel (A.B.C), then typing ISMF is ambiguous. Do you get your panel SELECT option, or do you get the command table entry? The two results may differ depending on how things are coded. Users may not be happy. ;-( . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of ITschak Mugzach Sent: Thursday, January 16, 2020 10:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Starting an application in ISPF And even simpler, add it's and select cmd options to your ispf command table. This way you can type a short name to invoke it. ITschak בתאריך יום ו׳, 17 בינו׳ 2020, 2:44, מאת Frank Swarbrick < frank.swarbr...@outlook.com>: > This works. Thanks much. > > > From: IBM Mainframe Discussion List on > behalf of Steve Smith > Sent: Thursday, January 16, 2020 5:16 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Starting an application in ISPF > > Just write and invoke a simple exec (or clist if that's your thing): > > /* REXX */ > ADDRESS ISPEXEC > 'SELECT PGM(DGTFMD01) NEWAPPL(DGT) SCRNAME(ISMF)' > EXIT > > You could also invoke it from option 7.1 (Dialog Test), but that adds > some overhead. > > sas > > > On Thu, Jan 16, 2020 at 6:47 PM Frank Swarbrick < > frank.swarbr...@outlook.com> > wrote: > > > Doesn't work for me. Must not be in my "profile" or something. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C using Z/OS macros in C macros
The %0 and %1 are parameters to the __asm function, it will do the substitution
of the 2nd and 3rd parameter in the __asm(...) invocation into the %0 and %1
spots in the 1st parameter.
And I concur with your description - the *invocation* of the "SETUP(...)" macro
will specify the variables to be used and *those* variables are the ones that
need to be defined, "xx" and "yy" in your example.
If the OP (Mr. Reichman) codes the *invocation* of the SETUP macro as follows:
SETUP(supstate,key)
Then both "supstate" and "key" must be defined C variables.
The __asm function does not *define* variables, it just *uses* them. The
variables mentioned in an __asm invocation must already be defined in the C
code.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
retired mainframer
Sent: Friday, January 17, 2020 11:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Metal C using Z/OS macros in C macros
In you C code, when you "invoke" the macro, you would provide the values of the
two macro parameters. Something like
SETSUP(xx,yy)
It is the xx and yy that would show up inside the two parenthetical expressions
in the generated code. Keep in mind that a C macro performs simple text
substitution long before the actual compilation starts.
Based on the generated code you show, you would not terminate the above
invocation with a semicolon.
I've never used __asm but is
__asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(xx), "=s"(yy) ) what you want
the compiler to see?
Are you using %0 and %1 to mean the macro parameters? That is not the way C
macros work.
It looks like there should be a line continuation back slash following the left
brace. I don't think you want the one that follows the right brace since there
is no following line.
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Joseph Reichman
> Sent: Friday, January 17, 2020 5:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Metal C using Z/OS macros in C macros
>
> Just wondering if I can do something like this
>
> #define SETSUP(supstate,key) \
> {
> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(supstate), "=s"(key) ) \
> } \
>
> Seems like the variables have to be defined
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C using Z/OS macros in C macros
I think % refers to C variable substitution
I wanted the text from the macro which I think the # does
> On Jan 17, 2020, at 11:07 AM, retired mainframer
> wrote:
>
> In you C code, when you "invoke" the macro, you would provide the values of
> the two macro parameters. Something like
>SETSUP(xx,yy)
> It is the xx and yy that would show up inside the two parenthetical
> expressions in the generated code. Keep in mind that a C macro performs
> simple text substitution long before the actual compilation starts.
>
> Based on the generated code you show, you would not terminate the above
> invocation with a semicolon.
>
> I've never used __asm but is
> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(xx), "=s"(yy) )
> what you want the compiler to see?
>
> Are you using %0 and %1 to mean the macro parameters? That is not the way C
> macros work.
>
> It looks like there should be a line continuation back slash following the
> left brace. I don't think you want the one that follows the right brace
> since there is no following line.
>
>> -Original Message-
>> From: IBM Mainframe Discussion List On
>> Behalf Of Joseph Reichman
>> Sent: Friday, January 17, 2020 5:22 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Metal C using Z/OS macros in C macros
>>
>> Just wondering if I can do something like this
>>
>> #define SETSUP(supstate,key) \
>> {
>> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(supstate), "=s"(key) ) \
>> } \
>>
>> Seems like the variables have to be defined
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C using Z/OS macros in C macros
In you C code, when you "invoke" the macro, you would provide the values of
the two macro parameters. Something like
SETSUP(xx,yy)
It is the xx and yy that would show up inside the two parenthetical
expressions in the generated code. Keep in mind that a C macro performs
simple text substitution long before the actual compilation starts.
Based on the generated code you show, you would not terminate the above
invocation with a semicolon.
I've never used __asm but is
__asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(xx), "=s"(yy) )
what you want the compiler to see?
Are you using %0 and %1 to mean the macro parameters? That is not the way C
macros work.
It looks like there should be a line continuation back slash following the
left brace. I don't think you want the one that follows the right brace
since there is no following line.
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Joseph Reichman
> Sent: Friday, January 17, 2020 5:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Metal C using Z/OS macros in C macros
>
> Just wondering if I can do something like this
>
> #define SETSUP(supstate,key) \
> {
> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(supstate), "=s"(key) ) \
> } \
>
> Seems like the variables have to be defined
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zOSMF - import manager translation issue
Well, that was quick. I figured it out. It needs to be opened directly as a workflow. I misunderstood the doc and thought it needed to be imported via import manager first. I still don't understand why it couldn't be viewed, but I am moving forward again. Chris -Original Message- From: IBM Mainframe Discussion List On Behalf Of Chris Parker Sent: Friday, January 17, 2020 9:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: zOSMF - import manager translation issue I seem to be missing something very basic here. I clearly have a translation problem, but I am not sure where to look next. I am in the import manager attempting to import the supplied izu_config_setup.xml workflow. When I attempt to view it, it displays garbage. The file is in the same format it was in after being installed with SMP/e. I have verified that the text is actually in UTF-8 format. I have tried tagging the file and setting the code page in USS. I have also set the USS environment to AUTOCVT(ALL). Nothing is working at this point. It's as if the import manager is expecting it to be in EBCDIC. This is on a z/OS 2.3 system. Has anyone run into this? Thanks, Chris --- NOTICE: This email and all attachments are confidential, may be proprietary, and may be privileged or otherwise protected from disclosure. They are intended solely for the individual or entity to whom the email is addressed. However, mistakes sometimes happen in addressing emails. If you believe that you are not an intended recipient, please stop reading immediately. Do not copy, forward, or rely on the contents in any way. Notify the sender and/or Imperva, Inc. by telephone at +1 (650) 832-6006 and then delete or destroy any copy of this email and its attachments. The sender reserves and asserts all rights to confidentiality, as well as any privileges that may apply. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. Please consider the environment before printing this email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
zOSMF - import manager translation issue
I seem to be missing something very basic here. I clearly have a translation problem, but I am not sure where to look next. I am in the import manager attempting to import the supplied izu_config_setup.xml workflow. When I attempt to view it, it displays garbage. The file is in the same format it was in after being installed with SMP/e. I have verified that the text is actually in UTF-8 format. I have tried tagging the file and setting the code page in USS. I have also set the USS environment to AUTOCVT(ALL). Nothing is working at this point. It's as if the import manager is expecting it to be in EBCDIC. This is on a z/OS 2.3 system. Has anyone run into this? Thanks, Chris --- NOTICE: This email and all attachments are confidential, may be proprietary, and may be privileged or otherwise protected from disclosure. They are intended solely for the individual or entity to whom the email is addressed. However, mistakes sometimes happen in addressing emails. If you believe that you are not an intended recipient, please stop reading immediately. Do not copy, forward, or rely on the contents in any way. Notify the sender and/or Imperva, Inc. by telephone at +1 (650) 832-6006 and then delete or destroy any copy of this email and its attachments. The sender reserves and asserts all rights to confidentiality, as well as any privileges that may apply. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. Please consider the environment before printing this email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Metal C using Z/OS macros in C macros
Just wondering if I can do something like this
#define SETSUP(supstate,key) \
{
__asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(supstate), "=s"(key) ) \
} \
Seems like the variables have to be defined
thanks
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tape problem
We have had IBM hardware and software support trying to fix this since the 8th. Looking back at our logs the first sign of problems was this: CBR3617I Unable to obtain the number of empty slots in library TAPELIB1. 10:41:54.44 STC05918 0090 CBR3710I LIBSERV failure occurred for library TAPELIB1. RC=0014, RSN=1408, REQTYPE=1A. Dean Nai On 1/17/20, 7:42 AM, "IBM Mainframe Discussion List on behalf of Nai, Dean" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >These are physical tape. No VTS. > > >Dean Nai > > > > > > > > > >On 1/16/20, 8:01 PM, "IBM Mainframe Discussion List on behalf of Russell Witt" >025adb32e6d7-dmarc-requ...@listserv.ua.edu> wrote: > >> EXTERNAL: Do not open attachments or click on links unless you recognize >> and trust the sender. >> >>Brian and Dean, >> >>Yes, you are correct. If you insert or define a new range of virtual-volumes >>to the VTS; that will drive the CBRUXENT (ENTRY) exit. If you have the CA 1 >>version active, that will set the ROBTY field correctly as well as telling >>OAM the status of the volume (active/private or scratch). And having the >>ROBTY field set correctly is VERY important to CA 1. After all, we don't want >>to call the Oracle/STK exit when a tape in the IBM VTS goes scratch and we >>don't want to call CA-Vtape when an Oracle/STK volume goes scratch. So, based >>on the ROBTY field we will call the appropriate interface module (if there is >>an appropriate interface module, not all virtual-tape solutions have one). >> >>The original problem that Dean had mentioned (the CBR3770I and CBR3769I >>messages) however, has nothing to do with CA 1. Those messages are being >>issued because OAM has somehow "lost" track of the volume and can't find it. >>If it is a virtual-volume, that would be very strange. If it is a physical >>volume that indicates that for some reason it isn't in the slot where OAM >>thought it had put it. How far apart and in what order to you receive the >>messages? If you get the CBR3770I first, and then the CBR3769I quickly after >>- that would be very strange and I would recommend contacting IBM. >> >>Russell Witt >>CA 1 Architect >> >>-Original Message- >>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >>Behalf Of Brian Fraser >>Sent: Thursday, January 16, 2020 3:12 AM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: Tape problem >> you forget to update the ROBTY and VENDOR fields >> >>I never update those fields. >>I just insert new volumes as scratch and the library takes care of everything. >>Unless it's handled by the INSERT exit? >> >>Brian >> >>On Thu, 16 Jan 2020 at 15:47, Brian Westerman >>wrote: >> >>> It's not normally a CA-1 caused problem. This is "normally" caused >>> when tapes are added to the VTS and you forget to update the ROBTY and >>> VENDOR fields so tht when a tape is used (and scratched) that CA-1 can >>> tell the VTS and OAM that it's again available. >>> >>> Someone always forgets to do this at most sites when they add tapes, >>> and it isn't a problem right away because it takes a while for the >>> tapes to come up and be reused. >>> >>> Brian >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, send >>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >> >>-- >>For IBM-MAIN subscribe / signoff / archive access instructions, send email to >>lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >>-- >>For IBM-MAIN subscribe / signoff / archive access instructions, >>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tape problem
These are physical tape. No VTS. Dean Nai On 1/16/20, 8:01 PM, "IBM Mainframe Discussion List on behalf of Russell Witt" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Brian and Dean, > >Yes, you are correct. If you insert or define a new range of virtual-volumes >to the VTS; that will drive the CBRUXENT (ENTRY) exit. If you have the CA 1 >version active, that will set the ROBTY field correctly as well as telling OAM >the status of the volume (active/private or scratch). And having the ROBTY >field set correctly is VERY important to CA 1. After all, we don't want to >call the Oracle/STK exit when a tape in the IBM VTS goes scratch and we don't >want to call CA-Vtape when an Oracle/STK volume goes scratch. So, based on the >ROBTY field we will call the appropriate interface module (if there is an >appropriate interface module, not all virtual-tape solutions have one). > >The original problem that Dean had mentioned (the CBR3770I and CBR3769I >messages) however, has nothing to do with CA 1. Those messages are being >issued because OAM has somehow "lost" track of the volume and can't find it. >If it is a virtual-volume, that would be very strange. If it is a physical >volume that indicates that for some reason it isn't in the slot where OAM >thought it had put it. How far apart and in what order to you receive the >messages? If you get the CBR3770I first, and then the CBR3769I quickly after - >that would be very strange and I would recommend contacting IBM. > >Russell Witt >CA 1 Architect > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Brian Fraser >Sent: Thursday, January 16, 2020 3:12 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Tape problem > >>> you forget to update the ROBTY and VENDOR fields > >I never update those fields. >I just insert new volumes as scratch and the library takes care of everything. >Unless it's handled by the INSERT exit? > >Brian > >On Thu, 16 Jan 2020 at 15:47, Brian Westerman >wrote: > >> It's not normally a CA-1 caused problem. This is "normally" caused >> when tapes are added to the VTS and you forget to update the ROBTY and >> VENDOR fields so tht when a tape is used (and scratched) that CA-1 can >> tell the VTS and OAM that it's again available. >> >> Someone always forgets to do this at most sites when they add tapes, >> and it isn't a problem right away because it takes a while for the >> tapes to come up and be reused. >> >> Brian >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
