topic Re: DCL script doubts in Operating System - OpenVMS

DCL script doubts

DCL script to shell scr — Wed, 04 Nov 2009 08:04:13 GMT

hi ,
this is vinay i have doubt abt converting following instructions which r in DCl to unix equivalents can anybody help ?

f$trlnm
set noverify
set verify
f$parse

submit/que=sjmpsc$batch/after="tomorrow+19:00"/log=cer_mgr_log:sjmpsc_oracle_backups.log -
/noprint/notify/keep/restart cust_proc:sjmpsc_oracle_backups.com

BACKUP/LOG/NEW

please help me

Re: DCL script doubts

Kris Clippeleyr — Wed, 04 Nov 2009 08:40:02 GMT

Hi,
Might I refer you to the book
"Unix for OpenVMS users" ?
See:
http://www.amazon.com/UNIX-OpenVMS-Users-Second-Technologies/dp/1555581552

Regards,
Kris (aka Qkcl)

Re: DCL script doubts

labadie_1 — Wed, 04 Nov 2009 09:51:49 GMT

set noverify -> sh +x
set verify -> sh -x

The lexicals functions do not exist in Unixland and it is a pity. So you can forget about f$parse, f$trnlnm (and the logical names do not exist too).

The Unix way is
some_command | grep some_text | cut ...
(cut is more or less a f$edit on a string)

Re: DCL script doubts

Joseph Huber_1 — Wed, 04 Nov 2009 10:37:28 GMT

Recently -in a different forum- somebody even asked for a general translator DCL -> shell, really!
Even if the syntax can be "translated", the semantics of commands and functions simply have no equivalent in "unix" land.
There are some implementations of DCL as a shell or interpreter (VX/DCL from sector7.com for example), which might be the easier way to port DCL procedures.

f$trnlnm: there is no such thing as logical names in unices.
shell variables come near in some cases, (symbolic) links for files may replace some uses.
One always has to see each individual use of f$trnlnm to understand what is wanted: is it simply a call to see if a name or variable is defined ?
is it a call to extract individual items of a search list ?
is it a logical name translation to use and handle a file-specification defined in the logical ?
Each of the uses requires a different "unix" equivalent (if any).

f$parse: "unix" has no strict file-specification syntax like VMS, so it depends again on the individual f$parse call to find a "unix" equivalent:
parse to find the device a file is on ? there is no device as part of a "unix" filespec, only a "root" directory if it begins with "/".
parse with default or related specs to complete a file-specification ??
parse to extract the file-name only ? (hint: basename in "unix")
parse to extract the file type ? (there is no equivalent in "unix", only widespread conventions to use the rest after the last dot in a filespec as "type").
parse to remove the version number ? there is no such thing in "unix".

submit: there is no standard batch queuing facility in "unix": You have to explicitly see the target "unix" system to find out its batch facility, all have "at", some "batch" or "nqs".

Re: DCL script doubts

Hoff — Wed, 04 Nov 2009 17:17:45 GMT

You're going to have to convert DCL to bash and to Unix native utilities and such, or to use hardware emulation or such and run OpenVMS on the Unix box.

Or you might look to use contract with one of the organizations that sell conversion and porting and compatibility tools.

If you've been contracted to provide this, then you're going to have to learn DCL and you're going to have to learn bash, and map the two. This isn't a small base of knowledge, either; there aren't all that many folks that are really good at both bash and DCL.

And there are no direct mappings for any of the cited commands, either.

Here are some related discussions:

http://labs.hoffmanlabs.com/node/741

http://labs.hoffmanlabs.com/node/225

Re: DCL script doubts

Rick Retterer — Wed, 04 Nov 2009 23:23:23 GMT

You may find some good information at this website...

http://rcr-www.med.nyu.edu/rcr/gcg/openvms_unix_differences.html

Re: DCL script doubts

labadie_1 — Thu, 05 Nov 2009 08:04:27 GMT

On that link, I disagree with

Unix -> Ctrl Z suspends a program
VMS -> nothing

never heard of
$ set proc/suspend...

???

Re: DCL script doubts

Sheldon Smith — Thu, 05 Nov 2009 15:31:25 GMT

"The Unix way is
"some_command | grep some_text | cut ...
"(cut is more or less a f$edit on a string)

Unless you are trying to do something very simple, you will probably find sequences like "do-something | grep | cut" to be, awkward if not painful.

I'd recommend learning something like Perl. There are a number of tutorial sites on the web, and quite a few beginning Perl books available. Personally, I used "Learning Perl", by Randal L. Schwartz, for about a year before needing to get deeper in Perl.

Re: DCL script doubts

Huc_1 — Thu, 05 Nov 2009 17:01:43 GMT

For some the older folks still around.

edit by Digital Press in the Vax Users Series

Title "UNIX for VMS Users" by Philip E. Bourne

I have copy on the shelf next me, It does a good job .. aahh quality ! where have you been

But to read this you have to quite knowledgeable in either Vms environment and/or Unix shell.

Maybe you can get still hold of a copy (DP ISBN 1-55558-034-3).

Enjoy life,

Jean-Pierre.

Re: DCL script doubts

Richard W Hunt — Thu, 05 Nov 2009 17:52:57 GMT

As an aside to Labadie:

Of the three basic non-executing states that are not resource-related or paging-related, SUSPEND is the "deepest" sleep, the others being HIBERNATE (HIB state) and Event Flag wait (LEF or CEF state).

SET PROCESS process/SUSPEND puts the process in SUSP scheduler state. SET PROCESS process/RESUME returns it to COM state.
SET PROCESS process/SUSPEND was described (in my VMS Operations class) as a way to stop a runaway process from eating your CPU alive and yet let you change your mind if you later decided you wanted this process to run a little bit more.

It has been a while since I played with these, but the main difference among the various voluntary sleep states is (I believe) that a SUSPENDED process cannot RESUME itself from an internal AST event. A process that is suspended needs external help to wake up.

By contrast, a hibernating process can execute an AST that performs a WAKE system service call on itself. A process in a WAIT state can execute an AST that sets an event flag and again, release itself back to COM state.

Regarding the mapping between UNIX & VMS functions, since the O/S are inherently different due to their different origins and growth paths, you will have to expect that some things don't map well.

For instance, OpenVMS "context" (a description of what a process can "see" at a given moment) includes a wider variety of possible things to be seen than are visible in most UNIX environments. The differences in the way file-search paths work is also a big issue.

I would seriously consider that at some point, a redesign of the application or process for the new environment. A simple conversion is not going to work perfectly simply because the system "styles" don't map perfectly.

Re: DCL script doubts

DCL script to shell scr — Sat, 21 Nov 2009 14:50:08 GMT

how to create job queue in unix ?
init/queue instruction creates job queue in DCL I need an equivqlent command in unix

Re: DCL script doubts

Steven Schweda — Sat, 21 Nov 2009 15:02:55 GMT

> how to create job queue in unix ?

"unix" is not a very useful description of an
OS. AIX, HP-UX, Solaris, Tru64, ... would be
more helpful.

man at

man -k queue

man queuedefs

For example:
http://docs.hp.com/en/B2355-60130/queuedefs.4.html

VMS and UNIX(like) operating systems are
different. Exact translations from one to
the other are generally not possible. You
might do better if you try to learn more
about your particular UNIX(-like) operating
system(s), and quit trying to translate the
untranslatable.

Re: DCL script doubts

Hoff — Sat, 21 Nov 2009 17:07:46 GMT

cron, launchd/launchctl, /usr/local/etc/periodic/, GNU batch, Condor or, well, most anything that a Google search or a trip through available listings including http://en.wikipedia.org/wiki/Job_scheduler might show as available on your platform.

As for Unix questions...

HP-UX forum:
http://forums11.itrc.hp.com/service/forums/familyhome.do?familyId=117

HP Linux forum:
http://forums11.itrc.hp.com/service/forums/familyhome.do?familyId=118

When posting questions, do consider not asking for a VMS feature by name; you're porting, which means you're going to be ripping out most of the OpenVMS features, and you will be replacing them with platform-specific alternatives. The Unix folks won't know the features of OpenVMS like you or the folks here do, but they will know how to answer questions like "What are the recommended unix job scheduling software packages for [platform]", or similar.

Asking Unix questions in an OpenVMS forum serves to delay your port, and (unless you happen to hit a Unix user here in the forum) may not get you the best available or the most current answer(s) for your particular Unix platform.

Re: DCL script doubts

DCL script to shell scr — Mon, 23 Nov 2009 05:36:47 GMT

thank you for the help.I am able to solve my most of the doubts.

$ name = f$getjpi(pid, "prcnam")
$ pgcnt = f$getjpi(pid, "ppgcnt")
$ wspeak = f$getjpi(pid, "wspeak")
$ astcur = f$getjpi(pid, "astcnt")
$ astmax = f$getjpi(pid, "astlm")
$ enqcur = f$getjpi(pid, "enqcnt")
$ enqmax = f$getjpi(pid, "enqlm")
$ pgcur = f$getjpi(pid, "pagfilcnt")
$ pgmax = f$getjpi(pid, "pgflquota")
$ filcur = f$getjpi(pid, "filcnt")
$ filmax = f$getjpi(pid, "fillm")
$ f$type(ctx)

please check the attached file also.
can anybody help me in understanding these functions and how to get same vvalues in unix/linux

Re: DCL script doubts

Steven Schweda — Mon, 23 Nov 2009 11:20:02 GMT

> [...] how to get same vvalues in unix/linux

> "unix" is not a very useful description of an
> OS. AIX, HP-UX, Solaris, Tru64, ... would be
> more helpful.

"unix/linux" is not much more helpful.

Uh, rewrite the "unix/linux" kernel? What
makes you think that these VMS parameters
have any analogues in "unix/linux"?

> please help me

You don't seem to be paying attention.

Re: DCL script doubts

Hoff — Mon, 23 Nov 2009 14:52:56 GMT

The vmsbackup tool; a tool that can read (but not write) BACKUP saveset on Mac OS X, Unix and Linux boxes:
http://labs.hoffmanlabs.com/node/817

The bash analogs of DCL set noverify and set noon:
http://labs.hoffmanlabs.com/node/740

General list of DCL commands to bash commands:
http://labs.hoffmanlabs.com/node/741

There are no analogs to the logical name mechanisms and services including sys$trnlnm, DEFINE command, and the f$trnlnm lexical function, though there are alternatives. That DCL code will need to be replaced.

Filename handling and filename parsing is completely different between Unix and Linux and that of OpenVMS; that code will need to be entirely replaced.

Re: DCL script doubts

DCL script to shell scr — Mon, 23 Nov 2009 17:44:47 GMT

i need to now what those functions actually return the values

Re: DCL script doubts

Hoff — Mon, 23 Nov 2009 18:00:40 GMT

Please talk to your manager or (depending on your organization) your project leader about your requirements and questions here.

Your manager (or project leader) is best positioned to provide you with the organizational and technical guidance and resources that you are seeking here.

Certainly point your manager (or project leader) to these ITRC discussions, too.

Re: DCL script doubts

Willem Grooters — Tue, 24 Nov 2009 14:25:58 GMT

The VERY BASIC solution for your problems is EDUCATION.
You should have a fair understanding of the OS's you're dealing with. The more different these are, the more important this is - as you have experienced.
Without that knowlegde, you'll keep running into issues because you have no clue on what it means.

If you look around (on openvms.org, for instance) you'll find a lot of places to egt training and gain experience - free, if you like.
If you have access to a VMS system, use HELP on that system to find out.

Re: DCL script doubts

Hoff — Tue, 24 Nov 2009 15:21:46 GMT

I am aware of very little available material on this topic area; on porting OpenVMS software to Unix platforms, and for porting code from DCL to bash.

I've posted a very general porting sequence here:

http://labs.hoffmanlabs.com/node/225

This is a very technical undertaking, regardless.

Most any port requires detailed knowledge of both OpenVMS and of the target Unix platform; of the source and target of the port. This knowledge might be known to one person, or it might be case where a programmer familiar with the application and with OpenVMS creates a general design and requirements specification for an engineer familiar with Unix to review and implement. That design document does not and would not and should not include references to f$trnlnm or to logical names or another such OpenVMS features, but rather contains the purpose behind those references; the requirements and not the implementation.