Example 11: Read an IMS™ database sequentially
In the following example, File Manager Service Provider REST API calls are issued to start a persistent session to read segments from an IMS™ database, using a File Manager/IMS view to map fields in each segment.
This example assumes that a service archive has been created and deployed that maps an IMS™ database with a matching view. For example, the service archive could be created using the following properties file:
name=fmExample11
description=IFB2:HDOU#1 MAPPED BY MY.IMS.VIEW(HDOU#1)
version=1.0
provider=filemanager
host=10.1.1.2
port=9043
userid=admin
passwd=s3cr3t
ssid=IFB2
database=HDOU#1
regionType=DLI
view=MY.IMS.VIEW(HDOU#1)
timeout=300
connid=default
This example maps an IMS™ database HDOU#1 in subsystem IFB2 with a dynamic PSB (because psbMember is not specified), and a region type of DLI. The database is mapped by a File Manager/IMS view found in MY.IMS.VIEW(HDOU#1). This example assumes that the generated SAR file and APIs built in association have been deployed to your z/OS® Connect WLP server.
Initial request
An initial API call to read data from an IMS™ data resource requires an HTTP Basic Authorization header so that the caller can be authenticated for subsequent access to IMS™ data resources. For example:
Authorization : Basic dXNlcmlkOnBhc3N3b3Jk
where the string after the Basic keyword represents a Base64 encoding of userid:password.
All requests with a JSON payload also require a Content-Type header with a value of
application/json
.
The initial request does not need to name the data resource or provide view information because this information is already contained in the service archive associated with the API. Therefore, the API caller only needs to provide the optional operation and position parameters, if required:
{
"operation" :
{
"numSegments" : 1,
"session" : true
}
}
This request will read one segment from the beginning of the IMS™ database as filtered by the FM/IMS view. Any segments read will be mapped in the response by the view.
The service provider will persist a File
Manager/IMS
session because session
is set to true. The session will remain
active until a subsequent request is made with session
set to
false, or a timeout period of 300 seconds (5 minutes) elapses with no activity on
the session. This timeout period is preset in the service archive.
The caller can expect a token to be returned on an initial request when session
is set to true, and can use the token on subsequent calls without the need to pass a Basic
Authorization header.
Successful response
A successful response (HTTP Status Code 200) will be similar to the following:
{
"segments":
[
{
"PARTROOT":
{
"PARTROOT":
{
"ROOT-KEY": "3009280",
"ROOT-SPACES": " ",
"ROOT-TYPE": "02",
"ROOT-WOSNAME": "HOUSING CONV"
}
}
}
],
"token": "/u5qZ/hg8fX18fH29Pjz9WD39fnw8/k="
}
Subsequent read requests
The API caller can now make subsequent requests using the response token and reuse the FM/IMS session maintained by the service provider. For example:
{
"operation" :
{
"numSegments" : 1,
"session" : true,
"token": "/u5qZ/hg8fX18fH29Pjz9WD39fnw8/k="
}
}
The API caller can continue to read one or more segments at a time until a response segment
object has last
set to true, indicating that the last segment has been read. For
example:
{
"segments" :
[
{
"last" : true,
… other response fields
}
]
}
Ending the session
At this point, the API caller sends a request to terminate the active FM/IMS session.
{
"operation" :
{
"numSegments" : 0,
"session" : false,
"token": "/u5qZ/hg8fX18fH29Pjz9WD39fnw8/k="
}
}
Sending a request with session
set to false will always terminate the FM/IMS session, providing the token is valid. Since the caller has
already read the last segment, setting "numSegments" : 0
tells the service provider
not to attempt to read any more segments.