Connect:Direct (NDM) on Integrity VMS - trying to detect status
GerMarsh
I know there may be a very small audience for this but we are using
C:D (V3.4) on VMS 8.3 on Integrity.
We are having terrible problems in trying to determine whether a C:D
transfer has worked or not from the perspective of the calling command
procedure. Many versions ago, there was a /WAIT qualifier for the NDM
SUBMIT command which would return control - and final status - after
the (usually) asynchronous transfer submission completed.
That was then declared obsolete but we could use NDM_PROCSYNC to
perform the same function. This would be called immediately after the
NDM SUBMIT command and would synchronise with the transfer job to
allow the calling procedure to trap the status. That too is now
unsupported.
Although Sterling have actually no plans to obsolete /WAIT, it does
not work properly under some conditions.
We have tried local triggers with conditional statements and those too
won't work if there are particularly nasty problems.
As the underlying requirement is something like...
SUBMIT file for transfer
IF transfer successful THEN
Move original file to [.SENT] directory
ELSE
Move original file to [.FAILED] directory
ENDIF
... I won't have thought it was that tricky!
Any help or pointers gratefully received.
Thanks in eager anticipation,
Gerald.
Keith Cayemberg
> Hello VMS'ers
>
> I know there may be a very small audience for this but we are using
> C:D (V3.4) on VMS 8.3 on Integrity.
>
I have no personal experience with IBM's Sterling CONNECT: DIRECT
(NDM), but maybe I can still be helpful.
For those having no idea about this product, the homepage for the
product is here...
http://www.sterlingcommerce.com/products/managed-file-transfer/connect-direct/
Wikipedia also has some info/history here...
http://en.wikipedia.org/wiki/Connect:Direct
> We are having terrible problems in trying to determine whether a C:D
> transfer has worked or not from the perspective of the calling command
> procedure. Many versions ago, there was a /WAIT qualifier for the NDM
> SUBMIT command which would return control - and final status - after
> the (usually) asynchronous transfer submission completed.
>
Are you sure that's not a synchronous transfer? Waiting for
completion
of an operation before continuing is normally considered a
synchronous
operation. Asynchronous operations would normally allow continuing
script processing immediately. Error condition handling would then
need
to be performed within the asynchronous operation itself or by a
second
thread/process that is either signaled/called/AST'd by the asynch op
at
completion or by polling checks from a secondary thread/process.
I found documentation for CONNECT: DIRECT (NDM) here...
Connect:Direct® - Processes Language Reference Guide
http://www.scribd.com/doc/36139478/NDM-RefGuide
The OpenVMS specific sections are as follows...
Chapter 11 Connect:Direct OpenVMS Process Statements 113
Connect:Direct OpenVMS Process Statement 113
Connect:Direct OpenVMS Copy Statement 114
Copying from an OpenVMS Node to an OS/390 Node 115
Connect:Direct OpenVMS Run Job Statement 116
Connect:Direct OpenVMS Run Task Statement 116
Connect:Direct VM/ESA Submit Statement 117
Connect:Direct OpenVMS Conditional Statements 118
Connect:Direct OpenVMS Symbol Statement 118
Chapter 20 Connect:Direct OpenVMS Process Parameters 281
Example OpenVMS PROCESS Statement 322
Copying PDS Members from OS/390 to OpenVMS 354
Using the SYSOPTS Parameter (OS/390 to OpenVMS) 355
Copying a File from Disk to Tape (OpenVMS) 355
Copying a File from Tape to Disk (OpenVMS) 355
Copying from OS/390 to OpenVMS and Specifying a
User-Defined Translation Table 356
Copying a Single Entry from the OpenVMS Text
Library to an OS/390 Member 356
Copying All Entries from an OpenVMS Text
Library to OS/390 356
Copying a Data Set from an OS/390 Node to an
Executable File on an OpenVMS Node 357
Copying an Executable File from an OpenVMS Node to
an OS/390 Node 357
Copying a Text File from OpenVMS to Windows and
Back to OpenVMS 358
Copying between the z/OS and OpenVMS Platforms 358
Copying and Comparing Files on OpenVMS 359
Copying HFS and Text Files Back and Forth Between
z/OS and OpenVMS 360
Copying a Text File from OpenVMS to UNIX and
Back to OpenVMS 360
Copying a FB Text File to a z/OS PDS File and
Pulling Back to OpenVMS 360
Copying a Binary File from OpenVMS to Windows
and Back 361
Copying a Binary File from OpenVMS to UNIX and Back 361
Copying Files from VM to OpenVMS 384
Copying an OpenVMS File from Disk to Tape 392
Copying an OpenVMS File from Tape to Disk 392
Using Symbolics in an OpenVMS COPY Statement 392
Copying an OpenVMS Sequential File to a
Text Library 393
Copying a VSE Sequential File to an OpenVMS Node 393
Copying a File from OpenVMS to OS/390 and
Back to OpenVMS 440
Submitting a Process on OpenVMS 454
Submitting a Process with a RUN JOB on OpenVMS 463
Printing and Deleting the Log File on
Connect:Direct OpenVMS 464
Keeping the Log File on Connect:Direct OpenVMS 464
Printing and Keeping the Log File on
Connect:Direct OpenVMS 464
Run Job on OpenVMS 468
Submitting a Process with a RUN TASK on
OpenVMS from an OS/390 Node 475
Submitting a Process with a
Connect:Direct OpenVMS RUN TASK
from an HP NonStop Node 479
Submitting a Process with a Connect:Direct
OpenVMS RUN TASK from an OS/400 Node 480
Submitting a Process with a Connect:Direct HP
NonStop RUN TASK from an OpenVMS Node 482
Submitting a Process with a RUN TASK on OpenVMS
from an OpenVMS Node 484
Run Task on OpenVMS 489
Passing Parameters to a DCL Command Procedure from
a RUN JOB Statement (Connect:Direct for OpenVMS 498
Using the SYMBOL Statement to Build an
OpenVMS Filename 500
Chapter 29 Conditional Statements Examples 505
Using Conditional Statements (OpenVMS to OS/390) 505
Using Conditional Statements to Test for Process
Completion on OpenVMS 509
Using Conditional Statement on OpenVMS 509
> That was then declared obsolete but we could use NDM_PROCSYNC to
> perform the same function. This would be called immediately after the
> NDM SUBMIT command and would synchronise with the transfer job to
> allow the calling procedure to trap the status. That too is now
> unsupported.
The status provided in the symbol $STATUS by a submit command on
OpenVMS only tells you whether the job was successfully submitted to
a queue. The status says nothing about the success of the commands
or scripts performed within the submitted job. Since C:D appears to
be using the native OpenVMS batch facility, I would expect this to
also
be the case for C:D. I suspect that the SUBMIT command in the C:D
Process Language is also effectively asynchonous even with a WAIT
since
it is probably only waiting for the submit to queue to finish but not
waiting
for the submitted job to finish.
> Although Sterling have actually no plans to obsolete /WAIT, it does
> not work properly under some conditions.
>
> We have tried local triggers with conditional statements and those too
> won't work if there are particularly nasty problems.
>
I'm not sure what you mean by local triggers?
> As the underlying requirement is something like...
>
> SUBMIT file for transfer
>
> IF transfer successful THEN
> Move original file to [.SENT] directory
> ELSE
> Move original file to [.FAILED] directory
> ENDIF
>
> ... I won't have thought it was that tricky!
>
> Any help or pointers gratefully received.
>
Here's an OpenVMS Example from page 509 of the C:D Documentation...
Using Conditional Statement on OpenVMS
In this example, the Process runs a job on OpenVMS. It uses
conditional statements to
check the completion code from STEP01. If the completion code equals
0, a message is
issued to the operator indicating that the command procedure was
successful. If the
completion code is any value other than 0, a message is issued to the
operator indicating
that the command procedure failed.
PROC01 PROCESS SNODE=CD.VMS.NODE
STEP01 RUN JOB (DSN=DISK1:[USER1.PROC_CD1]DIR.COM
SYSOPTS=“NOPRINT LOG WAIT” SNODE
STEP02 IF (STEP01 EQ 0) THEN
RUN TASK (PGM=VMS PNODE SYSOPTS=“
CMD=‘REPLY/USER=USER1/BELL
BATCH_JOB_SUCCEED’"
ELSE
RUN TASK (PGM=VMS PNODE SYSOPTS=“
CMD=‘REPLY/USER=USER1/BELL
BATCH_JOB_FAILED’"
EIF
From my cursory reading of the documentation, it would appear you can
effectively use
conditionals only with the return status of STEPS that are performing
a COPY.
On page 282 I found...
The completion code from the RUN JOB statement is from the job
submission only
and is not the completion code of the submitted job.
It is strange to me that the conditional example on page 509 uses RUN
JOB,
although it provides no more information than that the job was
submitted but not that
it's contents completely successfully.
From the documentation it is not clear to me whether the RUN TASK
command is
providing a return status. Although it states that the RUN TASK
performs the the
instructions in a detached process, it also always waits for the TASK
to complete
before continuing to process the C:D script. So RUN TASK is
synchronous, and if it
also provides a correct completion status of the detached process to
the STEP, then
maybe that will make the conditionals work the way you intended? I
have no way to
test this.
Alternatively, you may try creating your own error condition handling
using the available
DCL tools (group or job logicals, $STATUS, IF-THEN -ELSE, ON ERROR, F
$MESSAGE)
embedded in the jobs you are submitting.
> Thanks in eager anticipation,
>
> Gerald.
Hope this helps, and wasn't too simplistic an answer to your question.
Cheers!
Keith
GerMarsh
though.
I've finally sussed it by trapping the $STATUS from the SUBMIT to
ensure that was ok(ish!), then trapping NDM$$RC for the return code
then waiting for the submitted NDM process to complete. I then search
the statistics for the job to check for specific success strings, for
example with a COPY and RUN TASK.
We could not use the RUN TASK to check the status as under some
exceptions the conditional statement does not get executed.
I await Sterling's official response on how we do this on VMS.
Bye for now,
Gerald.