Re: SV: SV: SV: Debug Tool know how...
The first example has no debug tool variables (strings that begin with a
%); debug tool seems to be happy with explicit names in various
combinations, it's only when you attempt to use a debug tool variable
that it gets fussy. The only time I found a problem with explicit names
(not sure it qualifies as a problem) was when I specified the load
module name (either explicitly named, or via %LOAD) and the variable
name, with no intervening compile unit or block names. In that case,
debug tool was unhappy.
Hunter Cobb
The Trainer's Friend, Inc.
-
Thomas Berg wrote:
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] För Hunter Cobb
Skickat: den 5 mars 2008 21:28
Till: IBM-MAIN@BAMA.UA.EDU
Ämne: Re: SV: SV: Debug Tool know how...
Thomas,
Some experiments with AT CHANGE confirm Don's observations about
qualified names in COBOL. I've found that the Debug Tool 7.1 seems to
allow at most one variable-based name, provided it's the first name
reference in a series of name references. E.g., for a variable named
xyz, in block blk1, in compile unit comp1, in load module
lm1, you can successfully follow AT CHANGE with:
lm1::>comp1:>blk1:>xyz [no debug tool variables]
%block:>xyz[block qualification variable]
%cu:>blk1:>xyz [compile unit qualification variable]
%cu:>xyz [compile unit qualification,
omitting block specification
%load::>blk1:>xyz[load module qualification, with block
name]
%load::>comp1:>xyz[load module qualification, with compile
unit name]
%load::>comp1:>blk1:>xyz [load module qualification, with both compile
unit and block name]
Any attempt to precede a debug tool variable reference with either
another debug tool variable reference, or an explicit load module /
compile unit / block name seems to fail. I'm not sure whether
this is a feature or a problem; as you've noted, the documentation
leaves some room for interpretation.
This seems to contradict Your first ("succesfully") example ?
Or do I missinterpret You ?
For what it's worth, in COBOL, the compile unit name is the first
PROGRAM-ID in the source module. The block name is the same as the
compile unit name, unless you are referencing variables defined in
nested programs. A variable defined in a nested program's DATA DIVISION
would have the block name of the nested program's PROGRAM-ID,
but would have the compile unit name of the outermost program's
PROGRAM-ID. Most typically (i.e., in the absence of nested programs), compile
unit name and block name are the same, and you would normally only
specify one of the two. Load module name is, of course, the member name of the
executable program in the load library.
Hope this helps,
Hunter Cobb
The Trainer's Friend, Inc.
Many thanks for the help!
(With the use of "AT ENTRY" I made some progress...)
But how do ordinary cobol qualification work ?
Like "xyz OF abc OF ghi" etc.
I don't seem to get it right, despite "profreading"
the variable names and quals in the program. Do DT
require ALL quals for a variable ?
Like "xyz OF abc OF def OF ghi OF jkl" despite that
"xyz OF abc OF ghi" would be enough unique for COBOL.
(It's now quite late here, I will continue tomorrow.)
A part of my log:
...
* The ENTRY SISGB10 ::> SISGB10 breakpoint is replaced.
AT ENTRY SISMB10
PERFORM
QUALIFY CU SISMB10 ;
AT CHANGE WB20-CLNR-XX OF WB20-IMPORT-AVTAL-EV OF
SISMB20-DS
PERFORM
LIST WB20-CLNR-XX OF WB20-IMPORT-AVTAL-EV OF SISMB20-DS
;
END-PERFORM ;
AT CHANGE WB20-CLNR-LIKV-XX OF WB20-IMPORT-EV OF SISMB20-DS
PERFORM
LIST WB20-CLNR-LIKV-XX OF WB20-IMPORT-EV OF SISMB20-DS
;
END-PERFORM ;
AT CHANGE CLNR-LIKV OF MOD-BUFFER
PERFORM
LIST CLNR-LIKV OF MOD-BUFFER ;
END-PERFORM ;
END-PERFORM ;
* The Entry breakpoint command for SISMB10 :> SISMB1
Re: SV: SV: Debug Tool know how...
Thomas Berg wrote: -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] För Don Leahy Skickat: den 5 mars 2008 17:40 Till: IBM-MAIN@BAMA.UA.EDU Ämne: Re: SV: Debug Tool know how... On Wed, Mar 5, 2008 at 9:15 AM, Thomas Berg <[EMAIL PROTECTED]> wrote: [mailto:[EMAIL PROTECTED] För Don Leahy > Skickat: den 5 mars 2008 14:49 We runs ver 7.1 (upgraded recently from 6.1). If You have some examples of AT CHANGE and LIST with qualified variables I would be pleased if You can send any to me. BTW, I'm trying to use this code in pre-saved PDS-members to be run automatically in DT, if that make any difference. Thanks, Thomas Fully qualified names work for me: AT LABEL CXXMU21::>CXXMU21:>CXXMU21:>MAIN-OUTPUT Where CXXMU21 is my load module name. This also works for me: AT LABEL %BLOCK:>MAIN-OUTPUT And so does AT LABEL %CU:>MAIN-OUTPUT But not: AT LABEL %CU:>%BLOCK:>MAIN-OUTPUT and AT LABEL %LOAD::>%CU:>%BLOCK:>MAIN-OUTPUT Thanks! Looks like what I'm coding. (Except that I use "AT CHANGE".) Is that C++ modules ? Thomas _ Thomas Berg Specialist IT Utveckling Swedbank AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Thomas, Some experiments with AT CHANGE confirm Don's observations about qualified names in COBOL. I've found that the Debug Tool 7.1 seems to allow at most one variable-based name, provided it's the first name reference in a series of name references. E.g., for a variable named xyz, in block blk1, in compile unit comp1, in load module lm1, you can successfully follow AT CHANGE with: lm1::>comp1:>blk1:>xyz [no debug tool variables] %block:>xyz[block qualification variable] %cu:>blk1:>xyz [compile unit qualification variable] %cu:>xyz [compile unit qualification, omitting block specification] %load::>blk1:>xyz[load module qualification, with block name] %load::>comp1:>xyz[load module qualification, with compile unit name] %load::>comp1:>blk1:>xyz [load module qualification, with both compile unit and block name] Any attempt to precede a debug tool variable reference with either another debug tool variable reference, or an explicit load module / compile unit / block name seems to fail. I'm not sure whether this is a feature or a problem; as you've noted, the documentation leaves some room for interpretation. For what it's worth, in COBOL, the compile unit name is the first PROGRAM-ID in the source module. The block name is the same as the compile unit name, unless you are referencing variables defined in nested programs. A variable defined in a nested program's DATA DIVISION would have the block name of the nested program's PROGRAM-ID, but would have the compile unit name of the outermost program's PROGRAM-ID. Most typically (i.e., in the absence of nested programs), compile unit name and block name are the same, and you would normally only specify one of the two. Load module name is, of course, the member name of the executable program in the load library. Hope this helps, Hunter Cobb The Trainer's Friend, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CICS 3.1 Installation and Web Services for CICS
You might want to distinguish between using CICS as a web server (check the CICS TS 3.1 Internet Guide, SC34-6450), and using CICS as a Web Services provider (check the CICS TS 3.1 Web Services Guide, SC34-6458). As a web server, CICS can deliver both static web pages and application-generated pages. As a Web Services provider, CICS responds to program-to-program requests from the web. FWIW, CICS can also act as a Web Services requester. From your original posting, it sounds like CICS as a web server is more what you have in mind. For this, you'll probably need to define several CICS resources: TCPIPSERVICE, DOCTEMPLATE, and URIMAP. The web services assistant programs DFHLS2WS and DFHWS2LS don't get involved when using CICS to act as a web server. Hope this helps. Feel free to contact me off list. Hunter Cobb The Trainer's Friend Kenneth R Barkhau wrote: Hello - We have CICS3.1 installed (up and running) and I am trying to find information regarding Web Services for CICS and how to implement and use. Is WEB SERVICES for CICS installed as a part of CICS 3.1? If so, is there some additional customization required for it? Any good 'cook books' out there or other good documentation ? Any hints, tips, or comments on this are greatly appreciated.I am primarily an MVS sysprog with rather limited CICS background. Our goal is to have users invoking CICS to go after Web pages for information. Thanks much. Regards, Ken Barkhau Duke Medical 2424 Erwin Rd. Durham, NC 27710 Telephone 919-681-2482 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: db2 question
Jacky Bright wrote: Hi .. few clarifications 1) After Revoking DBADM authority from user, is it necessary to bind all plans and packages associated with that user ? In our system in SYSTABAUTH there are few entries related to packages(grantees) for which AUTHHOWGOT field is D and grantor is user having dbadm authority. In case I remove DBADM authority from GRANTOR, will that affect operations of applications even if Grantor has execute prvilege on all packages. 2) when we say SET CURRENT SQLID = 'XYZ' while exeucuting any query what is mean by this .. Understandably If user ABC is part of group XYZ and database rights are assigned to XYZ then while executing any query thru ABC user we have to give current SQL ID as XYZ. JAcky -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html 1) If the SQL in the package/plan was allowed to be bound by virtue of the binder having DBADM on the data bases for tables referenced in the package/plan, then removing DBADM will cause the package/plan to be marked invalid. An automatic rebind will be attempted the next time the package/plan is accessed. The automatic rebind will succeed if all the necessary privileges are present for the package/plan owner; otherwise the automatic rebind will fail. Having the execute privilege on a package allows a prospective plan binder to name the package in the PKLIST parameter of BIND PLAN. A risk-avoiding alternative is to bind the packages/plans under a new owner before revoking the DBADM authority. A hindsight-based alternative is to BIND with an owner that's a group, not an individual. Removing the individual from the group leaves plans/packages with the group as owner unaffected. 2) SET CURRENT SQLID to a group affects subsequent dynamic DDL and DCL statements; privileges needed for the statement are derived from the CURRENT SQLID only. Dynamic DML SQL statements (INSERT/UPDATE/DELETE/SELECT) are normally authorized by the aggregate of privileges for a user and all of his/her groups. You need not set the CURRENT SQLID to avail yourself of this privilege aggregation. Setting the CURRENT SQLID also affects what is used for the owner for unqualified SQL (unless you also use SET SCHEMA). Hunter Cobb -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WebSphere Developer for z/Series
Check your program directories for details, but you probably want to install FMID H002600 for JES remote access, and FMID H001600 for Remote System Explorer, for z/OS data set and USS file access. For COBOL, PL/I, Assembler, and EGL support, you'll want FMID HEDS500. Also check out the Websphere Developer for zSeries Host Configuration Guide (SC31-6930). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
