1748171 Members
4245 Online
108758 Solutions
New Discussion юеВ

Re: COBOL and XAB

 
SOLVED
Go to solution
Richard J Maher
Trusted Contributor

Re: COBOL and XAB

Hi Hein,

I was curious how lib$find_file was populating the FID without opening the file. Do you (or anyone) have the source handy to check which RMS service(s) is called? Or does it hand-build the NAM?

Anyway, after I checked that yours works with a file opened with NOSHARE (how could I have doubted you :-) I thought "Oops! I better test mine". Anyway, in my haste for the original file I put in a few typos and realized Mick traditionally doesn't do a lot of call_status checking. When I thought my code was failing it just didn't like the SYS$MANAGER search list. (ss$_badparam) Feel free to drop that check if it bothers anyone.

Cheers Richard Maher

PS. Attached better version of com file.

PPS. Mick where are you? IIRC you used to leave at 3:00pm and used to be in early(ish) Perhaps another bank holiday at club you-know-what on the costa del you-know-what :-)
Hein van den Heuvel
Honored Contributor

Re: COBOL and XAB

Libb$find_file(_end) is just a friendly wrapper around SYS$PARSE + loop with around SYS$SEARCH, anchored by a FAB.
So you could use those RMS service to get FID and DID. RMS gets thos FID and DID from the on disk and in cache directories. It does not do an access, does not get to the file header in this context.

Cheers,
Hein
Mick O'Brien
Advisor

Re: COBOL and XAB

I must admit I like both solutions albeight Hein's one (via his 'hack') seems easier to implement and maintain. Addtionally to this the comment in his code (are you taking note Richard)....
*
* Attribute list. Values hard-coded. Obtained from :
* $ pipe libr/extr=$atrdef/out=sys$output sys$library:starlet.mlb | sea sys$pipe credate
*
*

...indicates how other file attributes can be accessed.

Now all I have to do is stick it into a BASIC program (maybe I should have started a forum entitled BASIC and XAB).

PS: Richard, COIN is now on 8.3 - that's what I was doing Friday night/Saturday morning
John Gillings
Honored Contributor

Re: COBOL and XAB

Mick,

>Now all I have to do is stick it into a
>BASIC program

This type of function is typically much more compact, easy to read and more general written in MACRO32.

Clearly portability cannot be a concern.

See attached file GETCRE.MAR

routine GET_CREATION_DATE(
file: input string by descriptor,
date: output quadword by reference)

No need for compiler licenses.
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: COBOL and XAB

>...indicates how other file attributes can
>be accessed.

Oops, forgot... to add attributes, add arguments and extend the attribute block. For example:

PUSHL #0 ; build attribute block on stack
PUSHAB @8(AP) ; return address for creation date
PUSHL #<!ATR$S_CREDATE>
PUSHAB @12(AP) ; return address for REVDATE
PUSHL #<!ATR$S_REVDATE>
PUSHAB @16(AP) ; return address for EXPDATE
PUSHL #<!ATR$S_EXPDATE>
A crucible of informative mistakes
Mick O'Brien
Advisor

Re: COBOL and XAB

John,

Thanks for the MACRO - I don't understand it but I linked it in with a COBOL and BASIC program and it worked! I also tried adding the attributes (just for COBOL) and they worked as well.

Not sure now which solution to go with: -

Hein's - as I can understand it and maintain but seems to use an undocumented 'hack'
Richard's - can't understand at all (and I won't say anything about the code ;-)
John's - easier to understand than Richards and simple to use (but not maintain)

Mick
Richard J Maher
Trusted Contributor

Re: COBOL and XAB

Big Mick,

Why Coutts would be using BASIC is an absolute mystery to me and, having had to code basic a few years ago, is one I'm happy to ignore.

As far as understanding my code goes, I could strip it down to bare bones but I left in some of the following validation that you may or may not find useful. The code checks: -
1) The length of the input file string is not greater than the maximum
2) The output FID address is non-zero
3) The filename does not contain a node-name as the code won't work over the network
4) Your file-spec does not contain a wildcard character or a search list that might lead to an ambiguous result
5) The DID from the $parse is not null
6) The device is in fact a disk and not a tape, mailbox etc

Now I'd personally put in about 1/2 doz more checks but I'm happy to take them out if you find the code confusing.

Also the code returns the FID and Expanded File-Spec as well as the output creation date. These can be removed also.

As far as additional output attributes goes, uhmmm. . . it's an item-list, yeh? Add more items to the list get more items? If you want you could have just 2 arguments, one the input filespec and the second the input item-list that you configure as you see fit.

As far as Hein's solution being a "hack" IIRC you/we already invested in a hack with EXTERNAL FDs in COBOL and overlaying RMS FABs and RABs in Macro on VAX. And we all know that went tits-up with Alpha which brought us to those crappy DCOB$ routines.

Anyway, I still vote for Hein's cunningly clever solution worthy of a Baldrick Turnip or two. The context is a FAB as Hein says, there's no one left to break it?

If you like to see a minimalist version of my code then let me know. Otherwise just go with Hein's and if it ever does break then you have a solution at hand.

Cheers Richard Maher

PS. Friday night *and* Saturday, that's gotta good for double time! Just like Y2K eh :-)

I bet Adam and Weirdo were in as well "monitoring". What did you do, log on? Make an enquiry?

Don't know weather it's better or worse that the tax-payer is now footing the bill over there :-)

PPS. Pepall was over the other week for a holiday
Mick O'Brien
Advisor

Re: COBOL and XAB

Richard,

Why don't you post your minimilist code and I'll give that a go THEN I can use whatever I want (and not tell anyone) so all will be happy with providing a solution to my question?

Mick

PS No BASIC code in the COIN application just an executable to view/monitor the overnight

PPS Over where - Oz or UK

PPPS 'whether' NOT 'weather'

PPPPS Just standard Costa Del rates
Richard J Maher
Trusted Contributor

Re: COBOL and XAB

Hi Tom (or was it Huckleberry?),

Can't believe I spent over 3hrs on a Sunday and just under an hour sitting in my cruds here this morning just to paint your fence. Disbelief!

Anyway see attached for the Jenny Craig version of the code. Look, I'm all for Macro and don't have a problem with maintenance issues but if this is the *only* Macro code you've got then KISS and go with Hein's.

Mark was here on hols, he still lives over there and survived the take-over at Meryll's. Doesn't get to Swan Lane much any more and most of his time is in Croydon. Denever Technology were getting big in HP Open View and other Enterprise Management stuff so he might be worth a call?

Cheers Richard Maher

PS. I've got a sexy bit of recursive C# that populates a TreeView control from and Oracle CONNECT BY. . .PRIOR if you want to see it :-)

Good to have an excuse to do MACRO for a change!
Richard J Maher
Trusted Contributor

Re: COBOL and XAB

Hi Mick,

I've attached a new version of the code to this. (No code changes just a some more useful comments.)

But I got to thinking about something noboby bothers with in IT anymore and that's performance. The internet is a sewer and ITRC is certainly not immune from sloppy ineficient code :-)

So for curiosity's sake (it involves getting off your bum and doing something so probably won't happen) why don't you run the different options through a couple of tests and compare the results. 1000 iterations with one file and another with 1000 filenames (perhaps across different disks?)

I believe Hein maintains that RMS's $DISPLAY references a cache and doesn't have to do lookups and should be faster. I seem to do both lookup and attribute retrieval in a single $qio to the device driver. Looks good to me; is it functionally equivalent? Does the inner-mode switch to RMS and Exec hurt performance? Is sys$display redundant?

All good questions.

Cheers Richard Maher