vms commands to unix

[Michael Boynay]

Hello All,

very little experience with either command language but I have been tasked to convert a file of vms commands to unix (now a hpux enviro).

I am unclear what would be the the unix equiv to
purge/keep=2
del/since=yesterday
back/log

any help you can provide or link to a reference would be greatly appreciated.

Thanks in advance.

here is the file
$ purge/keep=2 cer_log:charge_services_ftp.log*
$ define sys$output "cer_log:charge_services_ftp.log"
$ set noon
$ show time
$ del/since=yesterday CER_DATA:[TEMP.OUTBOUND.CHARGE_SERVICES_FTP]*.*;*
$ back/log cer_print:dcaptnameextfile*.*; CER_DATA:[TEMP.OUTBOUND.CHARGE_SERVICES_FTP]
$ back/log cer_print:icrextractfile*.*; CER_DATA:[TEMP.OUTBOUND.CHARGE_SERVICES_FTP]
$ back/log cer_print:dcamedservextfile*.*; CER_DATA:[TEMP.OUTBOUND.CHARGE_SERVICES_FTP]
$ back/log cer_print:UHS_NY_INV_SUM_BY_LOC.TXT; CER_DATA:[TEMP.OUTBOUND.CHARGE_SERVICES_FTP]
$ back/log cer_print:UHS_NY_UNREC_LIAB.TXT; CER_DATA:[TEMP.OUTBOUND.CHARGE_SERVICES_FTP]
$ ftp
lcd CER_DATA:[TEMP.OUTBOUND.CHARGE_SERVICES_FTP]
connect xx.xxx.xxx.xx
xxxxx
xxxxxxx
cd xxx
ascii
put *.*
exit
$ del/since=yesterday cer_print:dcaptnameextfile*.*;*
$ del/since=yesterday cer_print:icrextractfile*.*;*
$ del/since=yesterday cer_print:dcamedservextfile*.*;*
$ del/since=yesterday cer_print:UHS_NY_INV_SUM_BY_LOC.TXT;*
$ del/since=yesterday cer_print:UHS_NY_UNREC_LIAB.TXT;*
$ show time
$ exit

[OldSchool]

well...first you're going to have to define what that does in VMS-land.

I've not seen vms in years, but as I recall, purge/keep=2 tells vms to keep the last 2 versions of a given file and remove any others. There isn't anything equivalent in HP, as the filesystems don't provide the "version numbers" (xxx.xx;1 ;2 ;3????).

perhaps a better start would be determining what the expected results are to be?

[James R. Ferguson]

Hi:

I second OldSchool's remarks. That said, it would appear that you want to remove files based on their last modification timestamp's age. You can use 'find'.

For example, to delete files that are older than 30-days (haven't been modified in over 30-days) and bear the characters "_NY_" somewhere in their name and reside in the '/tmp' directory, you would do:

# find /tmp -type f -mtime +30 -name "*_NY_*" -exec rm {} +

the '-type f' argument limits things to files and not directories too. Enclosing the wildcard character string in double quotes keeps the shell from expanding it and lets the argument be handled by find().

Regards!

...JRF...

[Jan van den Ende]

Michael,

I am a VMS man myself, so please accept that my *X knowledge may be 'less than perfect'

-- purge/keep=2
is fully irrelevant, as any *X _ALWAYS_, unavoidably, does a fully automatic equivalent of PURGE/KEEP=1
-- SET NOON
I know no *X equivalent of that. What it does is, to IGNORE the first error it encounters, just go to the next command, and unSET NOon, so next time the default error action (whatever that is then) is taken. Maybe some *X expert can tell how to do that
-- delete/since=yesterday
I know of no equivalent. What JRF gave would be DELETE/SINCE=YESTERDAY/MODIFIED
The VMS command selects based on CREATION date-time.
Of course, for files that are only created and then never modified, there is little difference.
-- BACKUP/LOG copies the specified file(s) to a special formatted file, and reports the processed files. It is functionally not too unlike the intension of TAR.

The thing that worries me most is the PURGE/KEEP=2 before BACKUP.
To me that suggests that there is interest in _TWO_ versions of the purged file.
If that is correct, then this needs a re-work to generate unique filenames for each instance; of course requiring to change the script to RM still older (already saved) files, change the save to handle TWO files.

In short, you need to find out the original _INTENDED_ functionality (you will need the assistance of those knowing the applic real well), and create a reasonable implementation of that functionality.

But, in my experience, migrations are seldom simple, and NEVER true copies of functionality... :-(

hth

Proost.

Have one on me.

jpe

[OldSchool]

Jan noted:

"DELETE/SINCE=YESTERDAY/MODIFIED
The VMS command selects based on CREATION date-time.
Of course, for files that are only created and then never modified, there is little difference."

OK, so that's going to be an issue, as UNIX doesn't know Creation date/time. It does know access time (atime in find), status change time (ctime) and modification time (mtime). Mtime would be create time if no modifications were performed.

And he also noted:

"The thing that worries me most is the PURGE/KEEP=2 before BACKUP.
To me that suggests that there is interest in _TWO_ versions of the purged file.
If that is correct, then this needs a re-work to generate unique filenames for each instance; of course requiring to change the script to RM still older (already saved) files, change the save to handle TWO files."

Which matches how I remember things...after a couple of decades. As I noted, UNIX doesn't comprehend versions, so this is going to be problematical as well. One way around it might be to set up two sub-directories, something like "ver1" and "ver2". Script would move ver2 to ver1, recreate ver2 and then write current versions to ver2 (higher # = later version). That probably wouldn't work in a scenario where some files change and others don't...

[OldSchool]

also of note:
"But, in my experience, migrations are seldom simple, and NEVER true copies of functionality..."

well, from one flavor/implementation of UNIX to another isn't to hateful, and I don't count Linux as a "flavor" (unless its the destination and not the source).

From one OS to another, well that can make you pull your hair out, as things that seem straightforward / logical may simply not exist in the destination.

You should be able to locate VMS / DCL command language references in yahoo or google.

Shelldarado (i think) used to have a fairly good set of Unix scripting tutorial (or try google for that as well).

Since you stated you know litte to nothing of the available commands, then some (or all) of the following might be useful:

Teach Yourself Unix in 21 Days
Teach Yourself Unix in 24 Hours
-or-
UNIX for Dummies
(nothing personal, its relatively brief)

One last thing that hasn't been mentioned is that there are a variety of command shells in various UNIXes, each with their own syntaxes. I can only offer the following:

1) csh (C-shell) is generally avoided, for a variety of reasons, which I won't go into here.

2) if portability is a concern (which I figure it always should be) then stick with a POSIX-compliant shell.

[cnb]

An additional references that may also be helpful:

OpenVms and Digital Unix Interoperability and Migration Guide EC-N7023-43

-and-

http://books.google.com/books?id=h-16rYWBfwMC

HTH,

[Jan van den Ende]

Michael,

Yesyerday I reacted much too strict to your question.

On second thought, you should have other issues, LOOOONG before you care about simple housekeeping trifles.

HOW is this app organised?
Does it __ONLY__ and purely use a database management system? And is that DBMS (or one very compatible/convertible) also available on the target platform? In that case you struck lucky big time.
Or (rather commom!) is this app implemented using (mult-)indexed files? In that case, there is no alternative but a complete re-design and re-write!

U*Xes have ONE type of filesystem only: any file is one sequential stream of bytes. Any structure must be implemented in the app itself. (the main reason why DBMSes are used: those implement data structures).
In contrast, VMS (or rather its file system, RMS, RecordManagementSystem) implements A LOT of structure, like the concepts of records and indexes (indices?).

Especially the oldest apps (from before DBMSes became prolific) are implemented leaning heavily on file structure logic.

Please do a DIR/FULL on the main application data storage file(s).
If any of those report File Structure: Indexed using (any number) of keys,
then seriously consider hiring a seasoned VMS specialist, just to describe WHAT is happening in the app at the implementation level.
(I myself am not available for work in the USA, but if you go to the VMS forum, several of the top-10 members are USA-based and provide such services, as of course do many others. Alternately, e-mail to Sue dot Skonetski at HP dot com , announcing a VMS position (plus approximate location) should attrack interested parties).

I hope to have given some useful hints, and not scared you too much.

Seasonal greetings,

Proost.

Have one on me.

jpe