Using DSKCOM for the first time and a bit confused about the way it works?

I thought DSKCOM worked like COMMON and that it would be a destructive read of a message - but it doesn't seem to be I can read the same message over and over again without rewriting it? I don't have SBR=COMMONNDR set.

If reading a message doesn't remove it what does? Do I have to blank the message, would that actually remove it?

Also, and this took a long time to find, on first call to DSKCOM it creates COMMON.SYS but doesn't create it with suficient permissions to be able to write to it so reading the message back returns nothing... (using RH Linux).

Barry

I tried to remember (without success) who provided the specs for DSKCOM.SBR. (I would have guessed it was you, but the fact that you are just now trying it suggests otherwise.)

In any case, sorry for the wasted time. (If it's any consolation, I've spent quite awhile myself this morning trying to figure this thing out.) The documentation does seem to imply (by saying that DSKCOM works like COMMON) that destructive read would be the default case. Whether by design or by accident, it is not the case. The routine hasn't been touched in many many years, so either it was never used, or it was the intended design, or maybe the users have just worked around it.

And in fact, there was no mechanism to actually delete a single packet. You could write blank data to it, but the packet would still exist (so your receive routine would have to test the contents as well as the existence of the packet). Or you could delete the OPR:COMMON.SYS file, but in that case you'd also be removing any other packets.

I'd be happy to change DSKCOM to use non-destructive read by default, but I'm afraid that might affect some existing application somewhere.

As for the permissions, this may have been a problem that evolved over time. The source code specifies the read and write permission flags when creating the file, but under GNU/Linux, these flags are now deprecated, in favor of flags that are specific to owner/group/other, with the old flags now indicating just owner. But Windows doesn't support the distinction and still uses the old flags, so I've now added conditional to explicitly request rw-rw---- (owner and group read/write) in the non-Windows case.

Note that if you had the +s bit set on the ashell executable (which is usually the preferred setting to allow a variety of inter-job communications, such as the ability to use SEND, JSTAT, KILL, etc.), rw------- would be all you needed, since all users would share the effective identity of the owner of the ashell executable.

But it's still a bug, which will be fixed in 6.0.1250.2.

Since an update is required, we might as well do something about the destructive read issue at the same time. My proposal is to implement a new opcode 3 which is like 1 (receive) but forces destructive read.

Let me know if that works for you and I can post an update over the weekend. But let me know also which version of Red Hat you're using, since there is now a compatibility bifurcation in the development/run environment between RHEL 4 (-el4) and RHEL 5 (-el5).

We do have a special xcall for storing limited data (xokey) with non-destructive read, but the data is lost when the job is closed so I would assume that it's not disk based.

Opcode 3 (destructive read) seems a workable solution as most of the time the non-destructive accident is useful.

Using RH5 presently. We used RH3 for some time and by the time we decided to move-on up RH5 was out so we skipped RH4 completely. I'm told we do have a couple of RH6 systems but they are working on same versions as RH5.

Barry

I mostly now use INIX.SBX to store and/or pass information between programs.

Usage:
XCALL INIX,INIFILE,TYPE,Section,Ident,Value,{default}

TYPE=0 is Read from INI
TYPE=1 is Write to INI
TYPE=2 is Delete Ident
TYPE=3 is Delete Complete Section

Example Read:
XCALL INIX,"TEST.INI",0,"LOCATION","TOWN",MY'TOWN,"ROYSTON"
This will read TEST.INI under section LOCATION for TOWN, MY'TOWN will
be set if found othewrise MY'TOWN is returned with the supplied default.
Default does not need to be supplied and blank is returned.

Example Write:
XCALL INIX,"TEST.INI",1,"LOCATION","TOWN","CAMBRIDGE"
This will write Cambridge to the INI under TOWN in the LOCATION section.
If the INI file,section or ident is not found they will be created.

Example INI File layout:
[LOCATION]
TOWN=CAMBRIDGE

Hi Steve

Hadn't come across INIX before - it's barely mentioned in the Ashell Developers Bible (otherwise known as Ty's Cookbook). Does it work between jobs?

Had a quick look at the source and I'm not sure it would be suitable in this case but I'll bear it in mind for future.

Thanks
Barry

The original version dates back to about 2004 (I think it was about then) and Jack has very much enhanced it over the years to improve the speed and multi user file locking.

I think the latest is 5.0(512) I upload it here.

"Does it work between jobs?" not 100% how you mean, but as its file based and can be shared between programs and jobs its pretty flexible.

XOKEY is closer to the standard COMMON (memory based and thus no sharing between jobs).

Steve makes an interesting observation that INIX, among its other virtues, works perfectly well as a means of passing arbitrary string data between jobs or programs.

It doesn't do so well with binary data though, and it doesn't have a destructive read option, so you would have to explicitly call it with the delete option to remove an item after reading it. Also, it's execution overhead is considerably higher than any of the variations of COMMON, although unless you're calling it thousands of times per minute, the difference is probably insignificant.

I'm not sure why we haven't documented it. Probably because it was an SOSLIB module, contributed by a "foreigner" (Steve). But various A-Shell modules now use it (including the APRNTSCRN utility, ATE, APEX, etc.), so it's pretty well entrenched. And despite the fact that INI-style files have gone out of style in the Windows world, they remain extremely convenient for several reasons (cross platform, easy to view and edit with any editor, persistent, self-documenting, etc.)

Those features may be overkill though for the kinds of low-level transient data passing typically done with COMMON and it's ilk.

I'll plan on posting an RH5-compatible (-el5) Linux update tonight with the DSKCOM patches mentioned above.

Here's the update: ash-6.0.1251.0-el5-upd.tz

Dev notes: ash60notes.txt