VAX Cobol Question - Legacy Cobol

[Jerome Ball]

Everyone,

I just looked at an old VAX COBOL program
and found lines in the procedure division that
begin with "/A", "/S", and others. They are
the first characters on line and in AREA A.

Like so:

XYZ-OPEN-IO.
CALL "SASFNM" USING XYZ-FILE-ID
MAR-RMS-FILE-NAME
MAR-CMD-TEXT.

\A CALL "QCMDEXC" USING MAR-CMD-TEXT
MAR-CMD-LEN.
MOVE "N" TO MAR-OK-SWT.
MOVE ZERO TO MAR-STATUS-CODE.
MOVE MAR-ALLOWING-ALL-VALUE
TO XYZ-ALLOWING-SWT.
\S MOVE "N" TO XYZ-LOCK-SWT.
PERFORM XXXX-XXXX.


There are hundreds of them and I don't have a clue what they mean. The code is
20 years old or more, it is currently running
VERY, VERY slowly and appears to work. I am
only looking at it to see if we can speed it
up. Any ideas on what these characters
represent?

Thanx in advance if anyone knows. Plz send some details or a link to understand. Plz reply to ballj_35@yahoo.com.

Jerome

[EdgarZamora_1]

\A is for Alpha
\V is for VAX
\I is for Integrity

dunno what \S means.

[Hein van den Heuvel]

Those backslashes (NOT "/A" like you wrote), are to do with Conditional Compiles. That's specified differntly based on Terminal versus ANSI Format. Check usersguide and REFORMAT tool.

They would NOT likely directly impact the performance of the functioning variant, other then perhaps adding logging to some such.

There are indications that RMS, and record lockign is being used here: "MAR-RMS-FILE-NAME", "MAR-ALLOWING-ALL-VALUE"

Now that coudl easliy be a source of performance trouble after a decade of neglect.

Typically that would show as the program becoming IO bound (low CPU, high DIRIO).
Or... if caching is effective, it could show as relatively high EXEC and KERNEL mode and unreasonable high (millions) of IO succeeding quickly.

So rather than starting at a chunk of random code, why don;t you describe what the real problem is you are trying to solve and provide some relevant info.
- Platform? Vax/Alpha?
- OpenVMS version?
- Batch or Interactive? How many concurrent users?
- Specific complaint? (xyz used to take n seconds, now m)
- Performance observations? CPU? MEMORY? IO?

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Hoff]

It's how COBOL does conditional compilation.

The backslash selector in the indicator area is whatever the programmer has selected; it's not tied to an architecture or most anything else.

You'll have to dig around in the associated DCL build procedures and/or in the available (local) documentation to determine the specific (local) meaning of these conditionals.

Where to head next here, in general terms? Characterize the performance. Profile the application code with one of various performance analysis tools. DECset PCA, for instance.

My bet? On zero evidence beyond the description, this slow-down is probably triggered by some sort of file fragmentation or disk fragmentation within some ancient and unconverted RMS file, or within a fragmented disk.

Typical performance of old COBOL code doesn't autonomously degrade (there's no baked-in obsolesce), though RMS access and other similar external considerations can result in performance degradations over time.

Various folks here have worked with COBOL, RMS, tuning and general OpenVMS, should you need "backstop support" in your current gig.

Stephen Hoffman
HoffmanLabs LLC

[Richard J Maher]

Hi Jerome,

They control conditional-compilation of the code. See the attached source for an example of debug specific code with "\d".

If you want the compiler to produce the code that is prefixed by those markers then you need to do something like this: -

$BUILD_IT:
$!
$! Compile the source files. P1 is checked to see wheter debug is required.
$ IF P1 .EQS. "Y" .OR. P1 .EQS. "y"
$ THEN
$ COBOL/NOALIGN/LIST/DEBUG/CONDITIONALS=D/NOOPTIMIZE DEMO_UARS.COB
$ LINK_QUAL = "/DEBUG"
$ ELSE
$ COBOL/NOALIGN/LIST DEMO_UARS.COB
$ LINK_QUAL = ""
$ ENDIF
$!

What the various switches do in your case, I have no idea :-)

Cheers Richard Maher