view release on metacpan or  search on metacpan

lib/DBD/MVS_FTPSQL.pm  view on Meta::CPAN

=item * 

a restriction to the previous rule is that the first character of every name segment can't be a number or a sign (-)

=back

If the dataset name is preceded by two slashes, then the path will be interpreted as absolute, 
otherwise the path will be evaluated as relative to the user home directory.
Valid values for this attribute are:   

  //FOO.BAR 
  //FIRST.SECOND.THIRD  
  DB2TEMP 
  ONE.TWO.THREE                

where the latter two are relative paths. If the user's home directory being connected with the mainframe is JSMITH and the preceding 
attribute L<remote_prefix|/remote_prefix> is set to
FDB2, then the temporary files will be created in the form:   

  //FOO.BAR.FDB2XXXX 
  //FIRST.SECOND.THIRD.FDB2XXXX 
  //JSMITH.DB2TEMP.FDB2XXXX 
  //JSMITH.ONE.TWO.THREE.FDB2XXXX  

where XXXX is the smallest zero-padded 4-digit integer that will produce an unique filename.
See how the total length of one of those dataset names must not exceed 44 characters.

=item C<timeout>

The "client" timeout. Specifies the maximum time in seconds the client 
will wait for a response from the server before signaling failure 
to the caller. The default is 120 seconds and should be appropriate for most situations.

Don't confuse the "client" timeout DSN attribute with the "server" 
timeout that is instead the timeout after which an idle connection to the 
database (the IBM FTP server, in our case) is closed. To hold a connection open 
and get rid of the server timeout you should periodically issue ping commands
(internally redefined as noop).

=back

=head2 How to find out the DB2 subsystem IDs

I've asked this question to the comp.databases.ibm-db2 group and
Jeroen van den Broek kindly answered me:

=over 4

Every DB2 subsystem has at least 3 address spaces associated with it,
the names of which all start with the subsystem-id (SSID):

  <SSID>MSTR = system services address space
  <SSID>DBM1 = database services address space
  <SSID>DIST = DDF (distributed data facility) address space

(next to these, you might have others, like the Stored Procedures
address space and the IRLM (Integrated Resource Lock Manager) address
space, but naming for these is not fixed)
You should be able to identify your SSID's via SDSF's "Status
Display" (option ST on SDSF's Primary Option Menu).
Use the following subcommands to show the various types of fixed
address spaces:

  SELECT *MSTR
  SELECT *DBM1
  SELECT *DIST

from which you can deduct your SSID's. 

=back

Note that SDSF (System Display and Search Facility) is an IBM product which interfaces with the MVS spool that,
among other things, allows the user to list all the jobs on the spool,
not only the ones whose name starts with his user-id.


=head2 Locking and concurrency considerations

This section discusses issues related to how the intrinsic constraints of 
the "SQL through FTP" feature influence the concurrent access of data.
An explanation of the concepts behind locking, concurrency and the way DB2 implements 
it is far beyond the scope of this document and although a brief introduction of 
isolation levels is provided, that knowledge is taken for granted.
Please consult your DB2 documentation for a more thorough overview.
It is also worth checking out a couple of interesting articles of Roger E. Sanders published on Db2 
Magazine.

Ok, after having said that...       

IBM DB2 for OS/390 or later supports four levels of isolation. These, ordered from the more to the less 
restrictive, are: 

=over 4

=item Repeatable Read (RR)  

Share locks are acquired on all the rows referenced (not only
those ones that will be returned) and they are released only when the transaction is 
committed or rolled back. Other concurrent transactions
can't acquire exclusive locks on those rows (and hence will have to wait before
modify the data) until the transaction owning the locks terminates. This prevents any 
interference between transactions themselves (the same query issued multiple times within the 
same transaction will ever return the same data) but also decreases concurrency, 
causing a slow down in performance.

=item Read Stability (RS) 

Share locks are acquired only for those rows that are part of a result set.
This prevents dirty reads (the reading of uncommitted data) and nonrepeatable 
reads while phantoms phenomena (described below) can occur.
If a query is issued more than once in the same transaction, it may get additional 
(precisely phantom) rows, as another concurrent transaction can insert rows that match 
the search criteria of the query.

=item Cursor Stability (CS)  

This is the default isolation level. It locks only the row (the page) that is currently being returned. As the cursor leaves the row, the lock is released and acquired for the next one, until all the data is returned.
While this maximizes concurrency and prevents dirty reads it does not 
ensure that the data retrieved will not be changed by other transactions, so
if the transaction reads the same row of data more than once odds are it