Hello.
I was wandering if someone could explain to me (or point to some
manual) the process of mapping the addresses of host variables by DB2.
Especially I would like to know when DB2 decides to reinitialize the
addresses and even more when it decides not to do it.
Recently I've ben strucked with a problem of host variables defined in
LINKAGE SECTION, and it
took me some time to find the cause and solution for the problem.
Problem's fixed but i still would like to know more about the whole
process.
regards
Michał Osada
7  13713 
>
>
>>>misha<mi**** *****@gmail.com 11/16/06 9:07 AM >>>
Hello.
I was wandering if someone could explain to me (or point to some
manual) the process of mapping the addresses of host variables by DB2.
Especially I would like to know when DB2 decides to reinitialize the
addresses and even more when it decides not to do it.
Recently I've ben strucked with a problem of host variables defined in
LINKAGE SECTION, and it
took me some time to find the cause and solution for the problem.
Problem's fixed but i still would like to know more about the whole
process.
Can you explain in more detail what your issue is? What do you mean by
"reinitiali ze the address". All that DB2 does, as far as I can tell, is a
call to a DB2 routine passing the length and type of the host var, along
with (the address of) the host var itself. Take the following, for example,
which is part of a COBOL program after being pre-processed by DB2:
*exec sql fetch ft_select
* into :film-transactions
* end-exec
CALL "sqlgstrt" USING
BY CONTENT SQLA-PROGRAM-ID
BY VALUE 0
BY REFERENCE SQLCA
MOVE 3 TO SQL-STMT-ID
MOVE 7 TO SQLDSIZE
MOVE 3 TO SQLDA-ID
CALL "sqlgaloc" USING
BY VALUE SQLDA-ID
SQLDSIZE
SQL-STMT-ID
0
MOVE 3 TO SQL-HOST-VAR-LENGTH
MOVE 484 TO SQL-DATA-TYPE
MOVE 0 TO SQLVAR-INDEX
MOVE 3 TO SQLDA-ID
CALL "sqlgstlv" USING
BY VALUE SQLDA-ID
SQLVAR-INDEX
SQL-DATA-TYPE
SQL-HOST-VAR-LENGTH
BY REFERENCE FT-BRCH-NBR
OF
FILM-TRANSACTIONS
BY VALUE 0
0
etc...
As long as FT-BRCH-NBR OF FILM-TRANSACTIONS is an addressable item (defined
in working-storage or, if in the linkage section, properly addressed prior
to the DB2 call) there should be no problem. The "sqlgstlv" routine should
simply move the result of the proper column in to the three-byte field
FT-BRCH-NBR passed by the calling program.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
You should start by running your source code through the precompiler and
examining the generated Cobol code. (This means that the precompiler
must be a separate job step.) I don't have any samples handy but, if I
recall correctly, the parameters are passed by calling a piece of DB2
code and using the variables as parameters in the call.
Phil Sherman
misha wrote:
Hello.
I was wandering if someone could explain to me (or point to some
manual) the process of mapping the addresses of host variables by DB2.
Especially I would like to know when DB2 decides to reinitialize the
addresses and even more when it decides not to do it.
Recently I've ben strucked with a problem of host variables defined in
LINKAGE SECTION, and it
took me some time to find the cause and solution for the problem.
Problem's fixed but i still would like to know more about the whole
process.
regards
Michał Osada
"Frank Swarbrick" <Fr************ *@efirstbank.co mwrote in message
news:4s******** ****@mid.indivi dual.net...
>>>>misha<mi*** ******@gmail.co m11/16/06 9:07 AM >>>
Hello.
I was wandering if someone could explain to me (or point to some
manual) the process of mapping the addresses of host variables by DB2.
Especially I would like to know when DB2 decides to reinitialize the
addresses and even more when it decides not to do it.
Recently I've ben strucked with a problem of host variables defined in
LINKAGE SECTION, and it
took me some time to find the cause and solution for the problem.
Problem's fixed but i still would like to know more about the whole
process.
Can you explain in more detail what your issue is? What do you mean by
"reinitiali ze the address". All that DB2 does, as far as I can tell, is a
call to a DB2 routine passing the length and type of the host var, along
with (the address of) the host var itself. Take the following, for
example,
which is part of a COBOL program after being pre-processed by DB2:
*exec sql fetch ft_select
* into :film-transactions
* end-exec
CALL "sqlgstrt" USING
BY CONTENT SQLA-PROGRAM-ID
BY VALUE 0
BY REFERENCE SQLCA
MOVE 3 TO SQL-STMT-ID
MOVE 7 TO SQLDSIZE
MOVE 3 TO SQLDA-ID
CALL "sqlgaloc" USING
BY VALUE SQLDA-ID
SQLDSIZE
SQL-STMT-ID
0
MOVE 3 TO SQL-HOST-VAR-LENGTH
MOVE 484 TO SQL-DATA-TYPE
MOVE 0 TO SQLVAR-INDEX
MOVE 3 TO SQLDA-ID
CALL "sqlgstlv" USING
BY VALUE SQLDA-ID
SQLVAR-INDEX
SQL-DATA-TYPE
SQL-HOST-VAR-LENGTH
BY REFERENCE FT-BRCH-NBR
OF
FILM-TRANSACTIONS
BY VALUE 0
0
etc...
As long as FT-BRCH-NBR OF FILM-TRANSACTIONS is an addressable item
(defined
in working-storage or, if in the linkage section, properly addressed prior
to the DB2 call) there should be no problem. The "sqlgstlv" routine
should
simply move the result of the proper column in to the three-byte field
FT-BRCH-NBR passed by the calling program.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
Hi All,
I've always assumed the DB2 Host variables must be in 'working storage'
If you try using host variables contained within a FD record
description - you never get the intended result - so I presume DB2 isn't
aware of any record reads causing the address of the fields within the FD to
change. I presume passing addresses via linkage has the same limitations. So
I alway move the items from linkage to WS and use them from there.
Bill
Bill wrote:
(...)
Hi All,
I've always assumed the DB2 Host variables must be in 'working storage'
If you try using host variables contained within a FD record
description - you never get the intended result - so I presume DB2 isn't
aware of any record reads causing the address of the fields within the FD to
change. I presume passing addresses via linkage has the same limitations. So
I alway move the items from linkage to WS and use them from there.
(...)
The problem with using host variables defined in LINKAGE SECTION is
that it usually works ;)
Error appears when you call your program containing sql queries from
two different programs.
Example:
PROG1 calls PROGX and PROGY.
PROGX and PROGY call PROGSQL which uses LINKAGE SECTION variables as
host variables.
Then "strange" things could happen. I was getting SQLCODE +100 on the
first query in the program. And I am sure that the record I was
reffering to was present in the table. After some experimenting it
turned out that the DB2 refers to a different place in memory than
COBOL variables. It looks like during the first call of PROGSQL DB2
remembers the addresses of host variables. During the second call the
addresses are not "reinitiali zed" and DB2 refers to the wrong place in
memory.
If the variables from WORKING STORAGE are used as host variables
everything is OK.
My guess is that because WORKING STORAGE is allocated separately for
each of the
calls of the PROGSQL program - DB2 reinitializes the addresses every
time the program is called. When the variables from LINKAGE SECTION are
used as host variables DB2 decides that it is not necessery, to
initialize the adresses again.
If the PROGSQL would be called only from PROGX using LINKAGE SECTION
variables as host variables it would propably cause no harm (although
I'm not completly sure of it).
Anyway - to solve the problem I decided to copy the contents of LINKAGE
SECTION variables to some WORKING STORAGE variables and use them in
queries. It helped.
I learned that I could also set the SQL-INIT-FLAG at the beginning of
the program to tell
DB2 to reinitialize the addresses - but I didn't try it.
I was wondering if someone have similar problems and maybe know some
more about how DB2 decides to initialize or not to initialize the host
variables addresses.
regards
Michal Osada
Bill<wf**@opton line.net11/19/06 12:50 PM >>>
>"Frank Swarbrick" <Fr************ *@efirstbank.co mwrote in message
news:4s******* *****@mid.indiv idual.net...
>
>misha<mi** *******@gmail.c om11/16/06 9:07 AM >>>
Hello.
I was wandering if someone could explain to me (or point to some
manual) the process of mapping the addresses of host variables by DB2.
Especially I would like to know when DB2 decides to reinitialize the
addresses and even more when it decides not to do it.
Recently I've ben strucked with a problem of host variables defined in
LINKAGE SECTION, and it
took me some time to find the cause and solution for the problem.
Problem's fixed but i still would like to know more about the whole
process.
Can you explain in more detail what your issue is? What do you mean by
"reinitializ e the address". All that DB2 does, as far as I can tell, is
a
>call to a DB2 routine passing the length and type of the host var, along
with (the address of) the host var itself. Take the following, for
example,
which is part of a COBOL program after being pre-processed by DB2:
[deleted]
>>
As long as FT-BRCH-NBR OF FILM-TRANSACTIONS is an addressable item
(defined
in working-storage or, if in the linkage section, properly addressed
prior
>to the DB2 call) there should be no problem. The "sqlgstlv" routine
should
simply move the result of the proper column in to the three-byte field
FT-BRCH-NBR passed by the calling program.
Hi All,
I've always assumed the DB2 Host variables must be in 'working
storage'
>
If you try using host variables contained within a FD record
description - you never get the intended result - so I presume DB2 isn't
aware of any record reads causing the address of the fields within the FD
to
>change. I presume passing addresses via linkage has the same limitations.
So
>I alway move the items from linkage to WS and use them from there.
I won't comment on using host variables in the file section, as there may be
other issued, but I see no reason why they could not exist in the linkage
section.
For example, I would think that something like this should work:
LINKAGE SECTION.
EXEC SQL BEGIN DECLARE SECTION END-EXEC
01 linkage1 PIC X(10).
01 linkage2 PIC S9(5) COMP-3.
EXEC SQL END DECLARE SECTION END-EXEC
PROCEDURE DIVISION USING linkage1, linkage2.
EXEC SQL SELECT DATA1, DATA2
INTO :linkage2
FROM TABLE_NAME
WHERE DATA1 = :linkage1
In fact I have used something like this (a bit more realistic, of course),
and had no problems.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
misha<mi******* **@gmail.com11/20/06 1:23 AM >>>
>
The problem with using host variables defined in LINKAGE SECTION is
that it usually works ;)
Error appears when you call your program containing sql queries from
two different programs.
Example:
PROG1 calls PROGX and PROGY.
PROGX and PROGY call PROGSQL which uses LINKAGE SECTION variables as
host variables.
Then "strange" things could happen. I was getting SQLCODE +100 on the
first query in the program. And I am sure that the record I was
reffering to was present in the table. After some experimenting it
turned out that the DB2 refers to a different place in memory than
COBOL variables. It looks like during the first call of PROGSQL DB2
remembers the addresses of host variables. During the second call the
addresses are not "reinitiali zed" and DB2 refers to the wrong place in
memory.
If the variables from WORKING STORAGE are used as host variables
everything is OK.
My guess is that because WORKING STORAGE is allocated separately for
each of the
calls of the PROGSQL program - DB2 reinitializes the addresses every
time the program is called. When the variables from LINKAGE SECTION are
used as host variables DB2 decides that it is not necessery, to
initialize the adresses again.
If the PROGSQL would be called only from PROGX using LINKAGE SECTION
variables as host variables it would propably cause no harm (although
I'm not completly sure of it).
Anyway - to solve the problem I decided to copy the contents of LINKAGE
SECTION variables to some WORKING STORAGE variables and use them in
queries. It helped.
I learned that I could also set the SQL-INIT-FLAG at the beginning of
the program to tell
DB2 to reinitialize the addresses - but I didn't try it.
I was wondering if someone have similar problems and maybe know some
more about how DB2 decides to initialize or not to initialize the host
variables addresses.
Are you using DB2 UDB for z/OS? My guess is that the pre-processor there is
somewhat different than the LUW pre-processor. Sounds like, as you say,
it's taking the address of the variable from the first call to PROGSQL and
using that as the address of the host variable even when PROGSQL is called
from another program (or even the same program if calling using different
data areas).
Anyway, since the SQL-INIT-FLAG is documented, why don't you use that?
From what I can see this should not happen for LUW, but I could be wrong. I
will certainly keep it in mind when developing my own subroutines! :-)
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
Hi all.
After digging through some manuals I finally found the answer (at least
I hope I did ;)
First I must add that the program I was having problem with is a batch
program.
Basically the problem with wrong host variables is caused by using
LINKAGE SECTION variables.
When program is called for the first time in a run-unit, it is loaded
and the memory for it's WORKING STORAGE is allocated. Until the
run-unit ends - address of WORKING
STORAGE are not going to change. When the PROG1 calls PROGX for the
first time, the
program is loaded and the memory for WORKING STORAGE is allocated. Then
the PROGX
calls PROGSQL passing it's own WORKING STORAGE variables to PROGSQL's
LINKAGE
SECTION. Because it is a first invokation of PROGSQL - the program is
loaded and the
memory for WORKING STORAGE is allocated. When the program PROGSQL
starts, it performs the section inputed by the DB2 precompiler:
PROCEDURE DIVISION.
DSNSQL SECTION.
SQL-SKIP.
GO TO SQL-INIT-END.
SQL-INITIAL.
MOVE 1 TO SQL-INIT-FLAG.
CALL 'DSNHADDR' USING SQL-VPARMPTR OF SQL-PLIST15 SQL-PVAR-LIST15.
(...)
The address of host variables are stored and the flag SQL-INIT-FLAG is
set to 1.
When the program PROGSQL is called from PROGY, the PROGSQL is already
loaded and it's WORKING STORAGE memory allocated. The flag
SQL-INIT-FLAG has been already set and the section, in which the
addresses are "remembered ", is skipped. Unfortunatelly the PROGSQL was
invoked for the second time with the LINKAGE SECTION containing the
variables from PROGY's WORKING STORAGE. And, naturally, PROGY's WORKING
STORAGE variables addresses differ from the PROGX's WORKING STORAGE
variables
addresses.
Conclusion:
- Do not use LINKAGE SECTION variables as host variables. Move them to
WORKING STORAGE variables which are safe to use as host variables.
- If you have to use LINKAGE SECTION variables as host variables you
must set the
value of SQL-INIT-FLAG to '0' at the beginning of the program.
I hope I expressed my thoughts in a clear way.
Thanks for help!
best regards
Michal Osada
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Chris |
last post by:
I have tableA, defined as:
field1 varchar2(10),
field2 varchar2(10),
field3 varchar2(10)
I have host variables defined as:
v1 pic x(10) varying
v2 pic x(10) varying
|
by: Zalek Bloom |
last post by:
Actually I would like to know what additional JCL I will need if a
COBOL non-DB2 program is calling to a COBOL/DB2 program. The original
non-DB2 program is executed using:
//STEP1 EXEC PGM=PROG1
I know I have to supply database name/plan to my program, but how?
Another question: what happens is the PROG1 program is a DB2 program
and is calling to another DB2 program with a different database and a
different plan?
|
by: Paul M |
last post by:
Hi,
This is on an AS/400 which can be a little strange but I think the
basic question is portable.
I have a (non-C) program that needs to make series of calls
to some C programs/functions. The problem is that I need to
initialise certain variables within the first C program called and
then use them in subsequent calls to other C functions.
|
by: Einar |
last post by:
Hi,
I wonder if there is a nice bit twiddling hack to compare a large
number of variables?
If you first store them in an array, you can do:
for (i = 0; i < n; i++) {
if (array != value) {
/* array differs from value, do something*/
|
by: singlal |
last post by:
Hi, my question was not getting any attention because it moved to 2nd
page; so posting it again. Sorry for any inconvenience but I need to
get it resolved fast. Need your help!
****************************************************************************************************
Original Question:
--------------------
Has anyone called a COBOL subroutine using COBOL CALL from a COBOL/DB2
| | |
by: dm1608 |
last post by:
We have a number of COBOL programs, and some were currently developing, that
simply read TEXT based reports and scrap the reports for various
information.
I'm curious to know if anyone has attempted to do this sort of thing using
C#?
I would love to get rid of my COBOL programmer and especially the code, if I
can. Apparently, it is much simplier to edit/parse text reports in COBOL
than other languages.... so I'm being told.
|
by: Frank Swarbrick |
last post by:
I'm just learning about embedded SQL, so be gentle...
My basic question is, if I use a fixed length host variable for a column
defined as VARCHAR, will trailing spaces be removed (or not) upon INSERT or
UPDATE of this column? I tried it, and it appears they are *not* stripped.
However, the Programming Client Applications manual leads me to believe that
the spaces should be stripped. A quote from that manual:
-------------------------...
|
by: Frank Swarbrick |
last post by:
A few weeks ago I had posed a question about how one my create a cursor for
a query where the predicate condition is dynamic. Meaning that the query
might want to have one of several possible predicates. Take the following
queries, for instance:
-- check for branch/account and amount
SELECT BRCH_NBR, ACCT_NBR, POST_DATE, AMOUNT, SERIAL_NBR, SEQUENCE_NBR,
POST_FLAG
FROM FILM.FILM_TRANSACTIONS
WHERE BRCH_NBR = 001 AND ACCT_NBR =...
|
by: rsilvers |
last post by:
what type of overhead will this select statement cause to db2 on z/os mainframe ? This is an imbedded SQL in COBOL
Declare cursor C1 for
select number, key1, key2
from table
where type = 'TYPE'
and number = :ws-number
and date(eff_date) <= :ws-start-date
and date(exp_date) >= :ws-end-date
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
