Re: Modernizing the BCP code ?
On Sat, 14 Apr 2012 00:44:19 +0800, David Crayford wrote: > >What I find the most disappoinging about that list is it forces you to >FLOAT(IEEE)! How useful is that for most assembler programs? I suppose >it's to keep the size of the runtime down >to only support functions for one floating point standard. That really >sucks! I could care less about ARCH(0) > Look forward, not back. HFP is _so_ 20th Century. And how much floating point of a particular flavor is needed in the kernel-type code which is the target environment of METAL-C? Disabling DFP may incur greater burdens. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Modernizing the BCP code ?
On Sat, 14 Apr 2012 00:13:31 +0800, David Crayford wrote: >I personally wouldn't use Metal-C for writing exits. Unless they are >very simple structures the DSECT conversion utility is painful due to >the ambiguous syntax of assembler data declarations. It takes a "best" >guess, which sometimes works and sometimes makes a horrible mess. > If the syntax were truly ambiguous, HLASM's behavior would be as unpredictable as METAL-C's. But perhaps it's undocumented. And the assembler enforces no type checking: FREDEQU * ... LHR1,FRED STH R1,JOE ... L R1,FRED ST R1,SAM ... What's C supposed to do with JOE = FRED? (But how does PL/S deal with it? Perhaps the DSECT conversion utility should employ the PL/S rather than the HLASM part of DSECT macros.) >The interesting thing about Metal-C is that the runtime is shipped as >part of the base operating system. So even if you don't have a C license >there's lots of good stuff in there. > Isn't much the same true for LE? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS every two years (Official announcment)
On Thu, 12 Apr 2012 10:01:57 -0500, Mark Zelden wrote: > >I use SoftCopy librarian to download / manage PDF bookshelves (per my last >post - for example, Tivoli since >bookmanager format is not available). > Is it ecumenical, or does it require a particular OS? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Modernizing the BCP code ?
On Thu, 12 Apr 2012 10:49:08 -0400, John Eells wrote: >Miklos Szigetvari wrote: >> >> Just got some REXX IRXINIT dumps, and seems to me the code is not very >> modern. > >> But "backwater" code that lives far away from any >frequently-traveled mainstream code path is an unlikely optimization target. > I'e hardly call IRXINIT "backwater". OTOH, it's not likely to be heavily traveled (thousands of executions rather than billions). And it has the base registers it needs for whatever it does. If it ain't broke, why fix it? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS every two years (Official announcment)
On Thu, 12 Apr 2012 16:25:27 +0200, Vernooij, CP - SPLXM wrote: >At least I would like the BOOKFIND command with its cursor sensitive arguments >to keep working. > >Do you really need the BOO format? Will a PDF reader with good searchable >index and BOOKFIND PDF support do too? > Too much bandwidth. I like to read a page without downloading an entire book. Can one search the entire z/OS 1.13 library for a given string in PDF format without downloading it? GIYF? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: realpath() syntax?
On Wed, 11 Apr 2012 12:52:16 -0500, Kirk Wolf wrote: > >Also, according to the documentation you will get an EINVAL error if the >second argument (the buffer) is NULL. > I thought I saw that this had changed, perhaps at 1.13, to implement a POSIX future direction. Alas, no; I must have been reading the OS X man page and displaced by wishful thinking. >On Wed, Apr 11, 2012 at 12:40 PM, McKown, John wrote: > >> #define _XOPEN_SOURCE_EXTENDED 1 >> >> as shown here: >> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/EDCLB1B0/3.791 >> >> or include the compile parm: -D_XOPEN_SOURCE_EXTENDED=1 >> Works. Thanks. I failed to note in POSIX the dependency on an option. OS X, Linux, and Solaris all compile it with no such special action. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
realpath() syntax?
z/OS 1.12. The source:
/* Doc: Print the resolved pathname of each argument
*/
#include
/* appears to contain:
char*realpath(const char * __restrict__,
char * __restrict__);
*/
int main( int argc, char ** argv ) {
char *resolved_name;
/* This is OK. */
realpath( "xyzzy", NULL );
/* This is OK. */
resolved_name = "wombat";
/* this gets:
ERROR CCN3068 realpath3.c:22
Operation between types "char*" and "int" is not allowed. */
resolved_name = realpath( "xyzzy", NULL );
}
My compile command is:
user@MVS:167$ gmake realpath3
LC_CTYPE= c89 -I.. -D_XOPEN_SOURCE -D_OE_SOCKETS -Wa,"ASA,RENT"
-DPLATFORM=OS390 -o realpath3 ../source/realpath3.c /usr/lib/Xaw.x
/usr/lib/SM.x /usr/lib/ICE.x /usr/lib/X11.x -lcurses -lm
in $ENV: /bin/sh -h $
ERROR CCN3068 ./../source/realpath3.c:22Operation between types "char*" and
"int" is not allowed.
CCN0793(I) Compilation failed for file ./../source/realpath3.c. Object file
not created.
FSUM3065 The COMPILE step ended with return code 12.
FSUM3017 Could not compile ../source/realpath3.c. Correct the errors and try
again.
Help!
Thanks,
gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Query about overcoming -- debunking, countering, and burying --mainframe myths
On Wed, 11 Apr 2012 07:04:45 -0500, Tom Marchant wrote: > >> A renowned industry expert ... >>[said] the 4341 might not be compatible with the 148 > >Not what you are looking for, but in the late 1970's, when I >was an Amdahl SE someone said that they understood that >the Amdahl was IBM-compatible, but would it run Cobol? > I understand that Hercules is zSeries compatible, but will it run z/OS? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Questions regarding SMS compacted dataset
On Wed, 11 Apr 2012 12:53:22 +0300, Yifat Oren wrote: > >Other utilities, such as IEBGENER. have to decompress the data set as they >are doing a record by record, logical, copy (this may not be true for IDCAMS >when using the compression interface, see II14507). > Is this done by the utility (ugh!) or by the access method? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS X-Windows (was: ASCII (was: Unix path name))
On Wed, 11 Apr 2012 09:27:28 +0200, Marian Gasparovic wrote:
>Just to add to what John said. Client and server glossary is reversed
>in X Window world. ...
>
No, it is not reversed. As elsewhere in the world, the server
LISTENs for a connection; the client requests to CONNECT.
It has nothing to do with size, importance, or influence.
As a parallel, when President Clinton (with an entourage
of bodyguards and reporters) walked into McDonald's
and ordered a hamburger, Clinton was the client; the
low-wage clerk behind the counter was the server.
On Wed, 11 Apr 2012 02:54:11 -0500, David Price wrote:
>
>Paul, thank you for the clarification that the original comment (about a
>possible lack of Curses, X11 and socket support) referred to the IBM XL C/C++
>compiler rather than z/OS UNIX.
>
(Which would have been unnecessary absent Shmuel's pedantry.)
You're welcome.
>So if the manuals are to believed, z/OS XL C/C++ should support Curses, X11
>and sockets from z/OS UNIX.
>
Curses and X11 are not supported with the Enhanced ASCII
option in effect (note the word "ASCII" in the Subject: line.
But the last time I tried it was several years ago.) I haven't
tried sockets with that option (but sockets should be a
prerequisite for X11).
In:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/edclb1c0/B.3
B.3 Library function support
Table 62 shows all the z/OS XL C/C++ Run-Time Library functions in
alphabetical order, their support of Enhanced ASCII processing and
their support of Preinitialized Environments for Authorized Programs.
Enhanced ASCII
Each function is identified by the extent to which it supports Enhanced
ASCII processing:
Yes = supports Enhanced ASCII.
No = does not support Enhanced ASCII.
Neutral = not sensitive to the issue of ASCII/EBCDIC character encoding.
Socket support appears to be present ("Yes"). Curses functions
aren't mentioned -- they don't even merit a "No". I see nothing
that resembles X.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: PL/I with variable PLISTs (was: LE C calling HLASM)
On Wed, 11 Apr 2012 00:48:33 +0200, Bernd Oppolzer wrote: >I would not blame PL/1 for this. >It is not OK IMHO to request the caller to set the >high order bit on the last parameter, when the number of the parameters is >fixed >(see also my GDDM example on the other post). This is not required by >any OS convention, >at least that's my understanding. > It's inconsistently deprecated. In: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a7b0/5.1.8 5.0 ATTACH and ATTACHX -- Create a new task Subtopics: * 5.1 Description Specify VL=1 only if the called program can be passed a variable number of parameters. VL=1 causes the high-order bit of the last address to be set to 1; the bit can be checked to find the end of the list. Note the word "only". But this admonition appears for ATTACH, but not for CALL. Is there any rationale for this difference, or is an RCF in order? (I haven't checked LINK nor XCTL; they're in a different volume.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Wish somebody had this for z/OS!
On Tue, 10 Apr 2012 10:53:34 -0500, McKown, John wrote: >http://www.idevcloud.com/Menu.htm > >This is a site where you can get a i/OS (iSeries aka AS/400) ... > Oh no! Another TLA war! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
z/OS (was: ASCII (was: Unix path name))
On Tue, 10 Apr 2012 08:41:26 -0400, Shmuel Metz (Seymour J.) wrote: >In <9575668525598233.wa.paulgboulderaim@bama.ua.edu>, on >04/08/2012 > at 03:58 PM, Paul Gilmartin said: > >>Overall, yes, but, last time I checked, no Curses; no X11. > >Those aren't ASCII issues. > Agreed. They're z/OS C/C++ compiler/RTL issues. Apologies for not changing the Subject: soon enough. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: USS YORKTOWN(was Accessing USS on Mainframe thru Telnet)
On Tue, 10 Apr 2012 15:27:29 +, Hal Merritt wrote: >I read about such, um, issues a while back. Seems that there were more and >more shipboard systems, but each was evolving on its own way lacking a common >strategy. That means the systems were often fundamentally incompatible and >therefore unable to communicate. Sounds silly, but I think an example was that >neither the radars nor the sonar could send target information to the guns. > >Say what you will about Windows, but it at least offered some potential >solution. ... > The solution is not Windows per se, but uniformity. There are specialized OSes used in, for example spacecraft, simpler and more robust which should be more suitable for embedded software. We seem to be back to the Bad Old Days of "No one ever lost his job for recommending IBM!" "C 'IBM' 'Microsoft' ALL" -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: OT: Keyboards for the archaic uber-geek
On Mon, 9 Apr 2012 08:39:17 -0500, McKown, John wrote: >I apologize, but others may find this interesting. Too expensive for me. > >http://www.etsy.com/shop/usbtypewriter > Also consider: http://xkcd.com/1031/ http://wiki.xkcd.com/irc/Leopard -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS X-Windows (was: ASCII (was: Unix path name))
On Mon, 9 Apr 2012 00:08:07 -0500, David Price wrote: >Looking at z/OS UNIX System Services "Ported Tools" >http://www-03.ibm.com/systems/z/os/zos/features/unix/bpxa1ty1.html >there is an X-Windows editor called "nedit" that IBM makes available for z/OS >UNIX. > >Does this imply that X-Windows under z/OS UNIX System Services is usable >(perhaps with IBM's Ported Tools)? >I guess if I really wanted to know I'd subscribe to the MVS-OE List Server. > Sam Siegel mentioned, approvingly, the Enhanced ASCII support in the z/OS C/C++ compiler and RTL. I partly concurred, but noted that C/C++ Enhanced lacks X11 and Curses libraries. Perhaps I didn't qualify my remark sufficiently; I had expected it to be apparent from the context. >On Sun, Apr 8, 2012 at 1:58 PM, Paul Gilmartin wrote: > >> On Sun, 8 Apr 2012 13:39:11 -0700, Sam Siegel wrote: >> > >> >The IBM XL C/C++ team did a GREAT jobs with ASCII compatibility. :-) >> > >> Overall, yes, but, last time I checked, no Curses; no X11. >> Sockets? I don't know. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
ASCII (was: Unix path name)
On Sun, 8 Apr 2012 13:39:11 -0700, Sam Siegel wrote: > >The IBM XL C/C++ team did a GREAT jobs with ASCII compatibility. :-) > Overall, yes, but, last time I checked, no Curses; no X11. Sockets? I don't know. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unix path name
On Sun, 8 Apr 2012 12:55:54 -0700, Sam Siegel wrote: > >Actually it is C. The intermediate buffer is used to allow the UNICODE >service to translate to ASCII. UNICODE services need to know how much data >is being passed in. The code runs POSIX(ON), XPLINK and is compiled the >ASCII option. > And then the C RTL will further translate it to the "native" EBCDIC. Many ASCII-centric systems treat UTF-8 as practically standard. (But the filenames contain nonportable characters.) Does the caller pass you ASCII, presumed ISO8859-1, UTF-8, or other? Will the files be shared (NFS?) or exported (pax?) to native ASCII systems? z/OS C, or Dignus? Hmmm... can Dignus programs interface to LE services for this sort of translation? gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unix path name
On Sun, 8 Apr 2012 11:15:55 -0700, Sam Siegel wrote: > >Paul - Thanks for the tips. The code does not create any path segments. > You're welcome. >My goal here is to be able to point the user to the reference manuals so >they can determine what is appropriate for their use. It is >their responsibility to allocate a buffer large enough to hold any >path/file name they create. When they call my function, they provide the >address of the buffer and the number of bytes in the buffer. A new buffer >is allocated (specified size + 2) and the specified number of bytes are >copied and a tailing x'' is appended. My buffer is passed to the >C/C++ runtime fopen function. If the path/filename provided is invalid, >the open fails and the error is returned to the caller. > Sounds like assembler code insofar as it uses address/length rather than a null-terminated string. So portability is less a concern. >It is >their responsibility to allocate a buffer large enough to hold any >path/file name they create. In which case, it depends not on a system limit nor on any limit in your code, but on how long a pathname the user intends to create. From what I glean from POSIX and the z/390 C/C++ RTL, the limits are to be regarded as dynamic, and available from dynamic queries by: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/edclb1b0/3.661 3.661 pathconf() -- Determine configurable path name variables which sounds sort of circular: in order to ask how long a pathname is allowed, you must provide some sort of pathname (in the same filesystem?) as input. The operant word is "configurable"; i.e. subject to change. The underlying Assembler callable service is: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bpxzb1b0/2.126 2.126 pathconf (BPX1PCF, BPX4PCF) (Yes, when I first learned about this, I thought it was BS; PITA.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unix path name
On Sun, 8 Apr 2012 09:55:46 -0600, Steve Comstock wrote: >On 4/8/2012 9:46 AM, Sam Siegel wrote: >> I'm trying to find the manual (by full name or number) that provides >> precise definitions about pathnames (hfs and zfs) for the unix subsystem >> on zos. Specifically, I'm interested in knowing the maximum length: >> >> 1) Entire path from '/' on down >> 2) Maximum number of characters in a file in a directory >>... > >1. 1023 > >2. 255 > This is probably in /usr/include/limits.h With some nasty associated facts that I learned when I was trying to write a command interface to realpath(): o realpath() appears to provide no protection against buffer overrun. o By descending a directory hierarchy, one can create a pathname far longer than that limit. o While many UNIX-like systems provide a definition of PATH_MAX in /usr/include/limits.h, POSIX deprecates this, and USS does not provide one. IBM gives the rationale that the limit is filesystem- dependent and code relying on it might become obsoleted by new technology. o A very deep path can cause "rm -rf" to fail in violation of POSIX spec with a "too many open files" error. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Accessing USS on Mainframe thru Telnet
On Thu, 5 Apr 2012 09:31:57 -0500, Chris Mason wrote: > >However, there are indications you have been seduced by the incorrect use of >the abbreviation for what started out as VTAM's Unformatted System Services at >least two decades before UNIX System Services appeared on the IBM scene. > Don't badger the novice. Vaunting your superiority is unseemly. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Seven-Digit JES2 Job Number
On Thu, 29 Mar 2012 08:59:09 -0500, Mark Zelden wrote: >On Wed, 28 Mar 2012 17:28:10 -0500, Dave Barry wrote: > >>We recently changed JES2 on a development z/OS LPAR to use seven-digit >>instead of five-digit job numbers. A coworker pointed out to me what >>appeared to be an increase in initiator input queue time on the LPAR after >>the change. My suspicion is that the increase was coincidental, but I have >>no way of conducting a true benchmark. >> >>Has anybody on the list noticed such an effect after converting to >>seven-digit job numbers? > >Nope, but it wouldn't shock me if it was related. You are treading new >territory > I'll be shocked on your behalf. Do you imagine it could be doing repeated linear searches of a 10,000,000 entry table? If so, they'll have to find a way to index it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Malicious Software Protection
On Sat, 31 Mar 2012 21:57:03 -0300, Clark Morris wrote: > >While z/OS is probably immune to executables being introduced from >outside, how vulnerable is a web server to outside attack (Apache, >Websphere, etc.)? Java on the server side is effectively executable >code. If dynamic SQL is allowed, I understand (but don't know for >certain) there are various interesting exploits. There is the story >about little Bobby Tables. SQL injection is apparently a problem that >I would assume could afflict DB2 under some circumstances. In short, >as I understand it, there are some vulnerabilities that do not require >machine language executable code. > While Little Bobby Tables is only a comic strip episode, I'm confident that various forms of code injection have been attempted and likely some have suceeded. Read all the alerts about buffer overruns. Apache invites coding CGI scripts in Rexx. Such scripts should avoid INTERPRET of a client-supplied string. Validating such a string with a script on the client side is pointless. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Rexx: load a module to storage
On Sun, 1 Apr 2012 09:38:11 -0500, Ray Overby wrote: >I am not aware of native rexx support for LOAD. You could write a rexx >function in assembler. I believe if you look at the CBT web site there >is at least a single example of this. > I found something at: http://www.cbttape.org/xephon/xephonm/mvs9802.pdf -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SNA future
On Fri, 30 Mar 2012 12:09:48 +0200, Jan Vanbrabant wrote: > >*Re. Technote T1013032 * > >*https://www-304.ibm.com/support/entdocview.wss?uid=isg3T1013032* > >*(Switching From DB2 Private Protocol (PP) to DRDA Protocol Question)* > >* However SNA is no longer a strategic protocol and customers are >advised to start converting their applications to TCP/IP. ... ...* > >For sure, we all know that SNA is no longer the strategic network >architecture. > >But such a statement from a major subsystem like DB2 is not negligible as >such. > I suppose the most important question is, when SNA goes away, will any three-letter acronyms associated with the product be retired and become available for reuse? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SNA future
On Fri, 30 Mar 2012 12:09:48 +0200, Jan Vanbrabant wrote: > >*Re. Technote T1013032 * > >*https://www-304.ibm.com/support/entdocview.wss?uid=isg3T1013032* > >*(Switching From DB2 Private Protocol (PP) to DRDA Protocol Question)* > >* However SNA is no longer a strategic protocol and customers are >advised to start converting their applications to TCP/IP. ... ...* > >For sure, we all know that SNA is no longer the strategic network >architecture. > >But such a statement from a major subsystem like DB2 is not negligible as >such. > Will it take VTAM with it? I understand VTAM is a major culprit in the dreadful terminal interaction of the TSO OMVS command/subsystem. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS ftp and Unicode
On Thu, 29 Mar 2012 13:38:33 -0400, Shmuel Metz (Seymour J.) wrote: >In <0342014919725794.wa.paulgboulderaim@bama.ua.edu>, on >03/28/2012 > at 09:10 AM, Paul Gilmartin said: > >>Quite so. Which is the reason I think FTP is in error for claiming >>the data contain an invalid code point. > >Did FTP make such a claim, opr did you misunderstand the error >messages? From Message-ID: ><1000645908993586.wa.paulgboulderaim@bama.ua.edu>: > >>ftp> quote site sbdataconn=(IBM-424,UTF-8) >>200-Some characters cannot be translated between UTF-8 and IBM-424 > >At this point FTP doesn't know whether you will be doing a get or a >put. The message is correct, although possibly misleading. > Gadi excerpted the transcript in: http://bama.ua.edu/cgi-bin/wa?A2=ind1203&L=ibm-main&P=770470 and it was further abridged when you quoted it. The larger sequence, from my own attempt, I posted in: http://bama.ua.edu/cgi-bin/wa?A2=ind1203&L=ibm-main&P=893422 is: Remote system type is MVS. ftp> quote site encoding=mbcs 200 SITE command was accepted ftp> quote site mbdataconn=(IBM-424,UTF-8) 200 SITE command was accepted ftp> get TEST.TESTPRT(TESTPRT) 200 Port request OK. 504 Multi-byte encoding not supported for RECFM=FB ftp> ftp> quit ... after the "get". The message is incorrect and misleading. For that matter, until it was named in the "get" the FTP server couldn't know the RECFM of the data set. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Detect SVC to Place Caller in Key 0
On Thu, 29 Mar 2012 11:00:15 -0500, Tom Marchant wrote: >On Thu, 29 Mar 2012 15:21:41 GMT, MD Johnson wrote: > >>Does anyone know what I could look for to detect when >>an SVC contains code to place the caller into and >>authorized state (key 0). > >You could run a GTF trace and examine all SVC calls and >returns. Key 0 is not an adequate test, though. You'd >have to test for supervisor state or any system key. >Even that is not sufficient, because you can't tell from >that whether they turned on JSCBAUTH. And then >there are PC routines > >If the SVC (or PC) passes control to an address supplied >by the caller, allowing the caller's code to run as part of >the SVC, you might be out of luck. > If the SVC (or PC) passes control with escalated privilege to an address supplied by the caller, isn't it ipso facto unsafe? But overall this sounds related to attempts to prove program correctness mathematically; a theoretical impossibility outside finite-state systems, and impractical for many systems with a large finite number of states. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Computerworld on LTFS
http://www.computerworld.com/s/article/9225514/As_60th_anniversary_nears_tape_reinvents_itself?source=CTWNLE_nlt_dailyam_2012-03-29 ... Lemmons can write a video file to a tape; the tape then shows up on any desktop, such as a Mac, Windows or Linux machine, and it presents itself just as if it were a hard drive volume. Hmmm. What OS is conspicuosly unmentioned? (But it's just a "such as".) ... Additional software is also required to ensure that any given customer's data is securely isolated from every other user on a given disk or array. In LTO tape environments, however, each tape cartridge is a separate object. This somewhat contradicts the earlier passage that LTFS makes a tape a general-purpose (presumably sharable) filesystem. Disclaimer: I'm employed by a company mentioned among the "major tape vendors" in the article. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Malicious Software Protection
On Wed, 28 Mar 2012 23:13:58 +0200, R.S. wrote: >The problem is we don't believe. :-) > It's easy. Bribe the sysadmin. (FSVO "access".) >W dniu 2012-03-28 22:45, Ray Overby pisze: >> Yes, I believe I have a way to attack a mainframe system where I don't >> have access. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS ftp and Unicode
On Tue, 27 Mar 2012 21:39:26 -0400, Shmuel Metz (Seymour J.) wrote: > >>WTF!? Didn't Shmuel tell us that UTF-8 contains all of Unicode? > >Yes, but I said nothiong about either IBM-424 or IBM-1047. Is there an >easy way to find what code point it's choking on? Also, I thought that >you wanted to tramslate IBM-424 to UTF-8, not UTF-8 to IBM-424. > Quite so. Which is the reason I think FTP is in error for claiming the data contain an invalid code point. Using a z/OS UNIX (whatever) temp file, it can all be done with a single FTP command and a bizarre script: # (Local stuff redacted) # MEMBER="$1" DSN=TEST.TESTPRT MVS_TEMP="/tmp/$MVS_USER" ftp $MVS_USER@$MVS_HOST < -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS ftp and Unicode
On Tue, 27 Mar 2012 15:43:18 -0500, Norbert Friemel wrote: > >UTF-8 is a variable-width encoding (1 to 4 Bytes/"octets" per character), it's >not a single byte character set. "sbdataconn" specifies single byte encoding. >Use "site encoding=mbcs" and "site mbdataconn=(IBM-424,UTF-8)" to specify >multibyte encoding. > Remote system type is MVS. ftp> quote site encoding=mbcs 200 SITE command was accepted ftp> quote site mbdataconn=(IBM-424,UTF-8) 200 SITE command was accepted ftp> get TEST.TESTPRT(TESTPRT) 200 Port request OK. 504 Multi-byte encoding not supported for RECFM=FB ftp> ftp> quit ... putting us right back at the original problem reported by the OP. -- gil >> >>The Roman characters in the file as transferred with >>sbdataconn=(IBM-1047,ISO8859-1) appear plausible. >> > >IBM-1047 and ISO8859-1 are both single byte character sets. > >Norbert Friemel > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Malicious Software Protection
On Tue, 27 Mar 2012 11:09:23 -0700, Skip Robinson wrote: >The reason I brought up this 'vulnerability' is that we hired a consultant >a while back to look for weaknesses. Of course they were able to logon >with a vanilla userid that had no special authority. And this is what they >did. > >We all spend a lot of time and mental energy focused on how to protect >ourselves from sophisticated attack. We look at APF. We look at SVC >screening. We look at access to sensitive libraries. But this particular >'denial of service' can be accomplished by anyone with a valid userid and >password. And *only* because we lock up users for invalid password >attempts. I'm just sayin'... > Would you and the auditors feel better if users logged on without typing passwords, via SSH with certificates stored on their desktops? Does SSH/SSL lock accounts on detected intrusion? There is an SSL flavor of tn3270, isn't there? And that would encrypt even LAN traffic. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS ftp and Unicode
On Tue, 27 Mar 2012 11:25:43 +0200, גדי בן אבי wrote: >The file http://gadib.tripod.com/images/ibm-424.xmit is a xmitted PDS >containing one member. >The text is in IBM-424. >The text in the line below new code is in Hebrew. IT should start with x'41'. > Thanks. After some munging, I get: 220-FTPD1 IBM FTP CS V1R12 at mvs, 17:42:18 on 2012-03-27. ... Remote system type is MVS. ftp> ftp> ftp> quote site sbdataconn=(IBM-424,UTF-8) 200-Some characters cannot be translated between UTF-8 and IBM-424 200 SITE command was accepted ftp> get TEST.TESTPRT(TESTPRT) local: TEST.TESTPRT(TESTPRT) remote: TEST.TESTPRT(TESTPRT) 229 Entering Extended Passive Mode (|||25580|) 125 Sending data set SPPG.TEST.TESTPRT(TESTPRT) FIXrecfm 80 00.00 KiB/s 557 Data contains codepoints that cannot be translated ftp> ftp> ftp> quote site sbdataconn=(IBM-1047,UTF-8) 200-Some characters cannot be translated between UTF-8 and IBM-1047 200 SITE command was accepted ftp> get TEST.TESTPRT(TESTPRT) test2 local: test2 remote: TEST.TESTPRT(TESTPRT) 229 Entering Extended Passive Mode (|||25582|) 125 Sending data set SPPG.TEST.TESTPRT(TESTPRT) FIXrecfm 80 00.00 KiB/s 557 Data contains codepoints that cannot be translated ftp> ftp> quote site sbdataconn=(IBM-1047,ISO8859-1) 200 SITE command was accepted ftp> get TEST.TESTPRT(TESTPRT) test3 local: test3 remote: TEST.TESTPRT(TESTPRT) 229 Entering Extended Passive Mode (|||25584|) 125 Sending data set SPPG.TEST.TESTPRT(TESTPRT) FIXrecfm 80 756 18.75 KiB/s 250 Transfer completed successfully. 756 bytes received in 00:00 (7.21 KiB/s) ftp> ftp> quit WTF!? Didn't Shmuel tell us that UTF-8 contains all of Unicode? (And all EBCDIC code points are defined in IBM-1047.) I gotta try this on 1.13 and submit a PMR. Or am I missing something? The Roman characters in the file as transferred with sbdataconn=(IBM-1047,ISO8859-1) appear plausible. Perhaps I should resubscribe to IBMTCP-L. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Malicious Software Protection
On Tue, 27 Mar 2012 11:15:52 -0400, Gross, Randall [GCG-PFS] wrote: >Ask your auditor to recommend one for the mainframe ;-) > That's likely not the auditor's job. But if he knows of none, it is his prerogative to assign a failing grade. However, what body certifies the available commercial AV products for PCs? Would RACF pass that certification? Would someone have to pay for it? How about penetration tests? Install a known virus in files on both PC and z. Run PC virus scanners. They'll report it. Is there anything that will scan (all!) z/OS data sets and report the virus? That z/OS itself is not infected may be of no import; the criterion may be that the latent presence of an agent infectious to other systems must not be tolerated. In this spirit, ClamAV for Linux scans Linux mail folders and reports (eliminates?) malware that is harmless to Linux but infectious to Windows. It's a shame that the insecurities of Windows impel such mickeymouse on better OSes. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Grace Hopper Stories!! (was RE: Pre-Friday fun: Halon dumps and POK Resets)
On Tue, 27 Mar 2012 09:06:30 -0500, John Gilmore wrote: >I like zMan's idea for a two-sided--nanosecond and millimeter--ruler; >his notion that the availability of the second, millimeter side would >make justifying its cost easy is a really inspired piece of nonsense. > >I wish I'd thought of it. > Earlier in this thread someone said 11 inches. Elsewhere, I've seen 9 inches or 8 inches. It depends largely on the speed of light in the insulation of the wire, which is not well controlled. Precise rulers are calibrated at a specific temperature; the nanosecond ruler needs to be calibrated for a specific propagation medium. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: XEDIT change in 6.2 ?
On Tue, 27 Mar 2012 06:55:42 -0700, Phil Smith wrote: >Tony Thigpen wrote: >>I have used that method also. But, it has the same problem. Anytime you use >>xedit with either (noprof or with a special, single purpose profile, the >>routines are most likely now broken. It's not something that can be fixed by >>a simple 'just change your profile xedit file'. It's also not something that >>could be addressed by using a system wide profile xedit that calls a userid() >>xedit. > >But my point was that in a macro, you have control over the case; if you stack >stuff, you're making assumptions about case translation. I wouldn't write: > >'command change /this/that/*' > >in a macro if I meant to change THIS to THAT; your technique allows/encourages >such sloppiness if you're assuming CASE U, because stuff will get uppercased >when it falls out of the stack. Yes, the subcommand above will do the same in >CASE U, but it seems clearer to me that it's wrong. > >Maybe this is just me... > What are you following up to? You've posted two replies in this (slightly OT) thread, and I see no antecedents. But, yes. I advocate a principle of minimal munging. Long ago, I tweaked my PROFILE XEDIT so I could open a binary file, make a one-character change (perhaps in hex) and save it with no collateral damage: No case changes elsewhere in the record; no tabs expanded; no sequence numbers modified. These should be the defaults for minimum astonishment factor. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - convrssion of Epoch (Unix) time to printable
On Tue, 27 Mar 2012 07:47:39 -0500, McKown, John wrote: > ..., the UNIX epoch is simply a number. The number of seconds since 00:00:00 > GMT 1 Jan 1970. It would be rather easy to convert to -mm-ddThh:mm:ss if > it weren't for the "leap seconds". Which may or may not be of any interest to > you. > Not really. In effect, the origin of NTP shifts by one second every time a leap second occurs. It is now 00:00:34 GMT 1 Jan 1970; in a little over 3 months it will be 00:00:35 GMT 1 Jan 1970. http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html ... it is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS ftp and Unicode
On Mon, 26 Mar 2012 11:22:38 +0200, ××× ×× ××× wrote: >I tried >quote site encoding=m >quote site mbdataconn=(IBM-424,UTF-8) > >and got: >504 MULTI-BYTE ENCODING NOT SUPPORTED FOR RECFM=FB > I'm curious: where might I find a sample of valid IBM-424 code to experiment with? (Damn Listserv! Gadi's name appeared properly in Hebrew (perhaps גדי בן אבי) in the article titles, but corrupted as above when I asked the web interface to quote the original text.) Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A z/OS Redbook Corrected - just about!
On Mon, 26 Mar 2012 16:29:18 -0500, Kirk Wolf wrote: > >a) don't use "USS" since it is not an official IBM acronym for z/OS Unix >b) don't correct someone who does. > You forgot: c) don't boast about your forays into (a) and (b). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A z/OS Redbook Corrected - just about!
On Mon, 26 Mar 2012 10:16:32 -0700, Dick Bond wrote: >I agree with Chris Mason. IBM should have never started called it USS - >how about a simple definitive abbreviation, like "zUnix". IBM adores >putting a "z" in front of everything (for some clueless reason) so why >should their version of Unix be any different? > Sigh. That would be at hazard for branding changes, complicating archive searches, etc. Is it free of trademark encumbrances? Would it be reasonably unambiguous in WWW searches (unlike zFS vis-à-vis ZFS)? (What do people use nowadays as a keyword for that product?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Leaving IBM
On Mon, 26 Mar 2012 08:52:45 -0500, Walt Farrell wrote: >I mentioned this over on RACF-L the other day, so for some of you this will be >old news. > >But the time has come for me to retire and have fun with other things. I've >enjoyed the discussions here, and working with many of you to plan >enhancements or resolve problems. I'm sure I'll still read both lists for >awhile, and probably even participate from a personal email address. > >But after Wednesday morning I will no longer be an active IBM employee and >I'll speak about z/OS and RACF even less officially than than I do now. > You'll be greatly missed. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS ftp and Unicode
On Mon, 26 Mar 2012 09:57:45 -0500, McKown, John wrote: > >Hebrew doesn't seem to be in UTF-8, looking here: >http://www.utf8-chartable.de/ > ".de" isn't the first place I'd look for Hebrew. And, as Steve pointed out, UTF-8 is effectively a transfer-encoding, not restricting the repertoire of Unicode. >None of which explains why the OP is having a problem since the conversion >would be from a single byte character set on z/OS to a multibyte character set >(Unicode) on Windows. > Amen. PMR time. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS ftp and Unicode
On Mon, 26 Mar 2012 08:09:48 -0600, Steve Comstock wrote: > >Get it working, put it in a script (REXX, CLIST, shell script); then >one line to invoke the script. Simple. > The "quote site ..." earlier in the thread suggests that the OP wanted to be able to operate the process from the PC side. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS ftp and Unicode
On Mon, 26 Mar 2012 15:41:50 +0200, גדי בן אבי wrote: >I am trying to transfer a file (PDS member) from z/OS to windows, so this >shouldn't be an issue. > Is IBM-424 a multibyte CP? If not, this should be a reportable defect. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Another JCL "wish".
On Thu, 22 Mar 2012 16:17:30 -0500, McKown, John wrote: >This may be another weird desire on my part. But I'm wondering why IBM does >not enhance the QSAM and BSAM access methods to support the OPTCD=Q and CCSID= >parameters on the DD statememt to work with datasets on media other than tape. >Especially z/OS UNIX files. There are times when I would really like to keep >some data in z/OS UNIX files using the ISO8859-1 code page. This works fairly >well with z/OS UNIX commands when I use the chtag and extattr commands to >properly tag the files. It would be really helpful to me if I could then read >those files into standard legacy applications using >PATH=...,FILEDATA=TEXT,RECFM=..,LRECL=..,CCSID=819 on the DD. There must be >some sort of code in QSAM and BSAM already since you can read ASCII tapes >using DCB=OPTCD=Q. Of course, I don't know how "creaky" that code is. I think >that IBM avoids touching some old parts of z/OS just out of fear. > OPTCD=Q uses the dreadful IGC0010C 7-bit translation table. Now, if you wanted (as you suggest) something like FTP's sbdataconn=(IBM-1047,ISO8859-1) facility, that might be meaningful. And, IIRC, FTP requires that one of the CPs be EBCDIC and the other ASCII (-like). Why not translate between two EBCDIC pages, such as 037<->1047, or even ISO8859-1<->UTF-8? (All things that iconv() (already supplied by IBM) does). (I almost forgot -- I hate EBCDIC!) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: UNABLE TO DELETE DUPLICTE DSN
On Thu, 22 Mar 2012 13:27:43 -0500, Tom Marchant wrote: >On Thu, 22 Mar 2012 11:59:09 -0400, Robert A. Rosenberg wrote: > >>Since the problem is that the DSN Name is enqueued upon (which is > >That's not what the OP wrote. The problem is that the data set is on >an SMS-managed volume and the catalog says that the data set is on >a different volume. > The OP wrote "is in use". That may reasonably be inferred to mean "open", "allocated", or "enqueued upon". We may now invite John G. to explain whether "is in use" is a stative verb or a dynamic verb, and what the OP intended by it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: UNABLE TO DELETE DUPLICTE DSN
On Thu, 22 Mar 2012 10:44:16 -0400, Sevetson, Phil wrote: >Rename the cataloged version to some [newname]. >Catalog the uncataloged version and rename it to some [newname2]. >Rename the [newname] back to the [original name]. > Won't work. >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of John Dawes >Sent: Thursday, March 22, 2012 9:24 AM > > ... the cataloged version which resides on volume MPR003 is in use, ... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: UNABLE TO DELETE DUPLICTE DSN
On Thu, 22 Mar 2012 07:42:39 -0700, Pesce, Andy wrote: >Even though it violates everything about being "Managed by SMS". >"IDCAMS Delete Noscratch" on a dataset that is SMS controlled will indeed >leave the >dataset on the volume. > Is this a bug or a feature? Well, I suppose you need to be able to clean up the catalog when a volume becomes physically and permanently inaccessible. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: rexx cpu intensive
On Wed, 21 Mar 2012 17:38:28 -0700, Cris Hernandez #9 wrote: > >-use DROP to free memory for any array that's no longer needed > But be careful. I have an example that shows that DROPping members of a stem can actually increase memory usage. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: rexx cpu intensive
On Wed, 21 Mar 2012 16:40:12 -0500, Jonathan Goossen wrote: >A way to simulate this is to accumulate the stem elements to a string and then iterate through them. If jobs is a string of job names... o Sometimes you haven't control over this: the compound may be defined by a host environment command. o The various tails may contain embedded blanks. n = words(jobs) do i = 1 to n job = word(jobs, i) if stem_var.job = ?. Other_stem.job = 'foo' etc. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: rexx cpu intensive
On Wed, 21 Mar 2012 21:04:34 +, Gibney, Dave wrote: > >Much of my growth in this field has been slow and steady. >The Rexx associative array realization is one of the "aha moments" I still >remember. > You can code FORTRAN in any language. You will sometimes be told that if your Rexx, Lisp, C++, ... code couldn't have been translated from FORTRAN by a filter with a small window it's ipso facto incomprehensible and won't pass coding standards review. >What I'd really like (is it there and I don't know?) is a: >for "each" stem_var. > say "each" > if each = > other_stem.each = 'foo' > etc. > Alas, no. I'm told that's available in OO Rexx. The Rexx API services will let you enumerate compound variable elements in an assembler (e.g.) program, and the tails could be fed back to Rexx as members of a linear array. Even that won't identify compound members individually dropped after a universal assignment. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Internet Service Retrieval
On Wed, 21 Mar 2012 15:46:47 -0500, Robert Heffner wrote: >We are finally being allowed to use Internet Service Retrieval for downloading >our software and service, and I have a general question to those who have been >using it. I have done several downloads of Shopz orders using RECEIVE >FROMNETWORK, and I notice that it is very slow. An order of about 770 MB in >size took two hours to download. If I had downloaded it to my laptop using >Download Director, it would have taken less than 10 minutes, and the upload to >the mainframe would have been just as quick. I can't get the network group to >look at it, and I don't know what routers, firewalls, etc are involved in this. > >My question is: is Internet Service Retrieval this slow for everybody? > Don't know; no experience; I'm not the sysprog here. But the problem can be partitioned: o Download to laptop; measure the time. o Upload to z; measure the time. o RECEIVE FROMNETWORK using LOCALHOST as your server; measure the time. Does one step stand out as the offender? Watch the SYSPRINT during the RECEIVE and time 3 phases: o Transfer (may be dominated by Java hash computation if you haven't properly configured ICSF.) o Un-pax and IEBCOPY to relfiles. o RECEIVE from the relfiles. Again, is there an outstanding offender? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: rexx cpu intensive
On Wed, 21 Mar 2012 19:53:34 +, Gibney, Dave wrote: >I once greatly improved a Rexx routine exploiting the associative Rexx > array. It was some extract from a TMS report. It was originally written like > any other array with a subscript variable. And a lot of for loops. > I changed it to use the main key (in this case the tape volser) as the > index. Elapsed and CPU times where reduced 80 to 90 percent. > Yes, but one must sometimes contend with readers of these lists who insist that Rexx compound tails _must_ be consecutive positive integers, and the count _must_ appear in the .0 member, because that's the way the only example they read did it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Prevent FTP from root
On Tue, 20 Mar 2012 13:25:09 -0500, Kirk Wolf wrote: >I can agree that OMVS segments should usually have their own directory. > It would be possible to have them share a common directory, but in that >case you would usually want to make it ready only, which would prevent some >z/OS Unix stuff from working but not, AFAIK, FTP. > >But in order to have complete control over FTP access, you may want to >implement a FTCHKCMD exit. See the z/OS Comm Server documentation for >details; a sample is provided by IBM. > Where's "chroot" when you need it? >On Tue, Mar 20, 2012 at 1:01 PM, Bruce Wheatley wrote: > >> We have numerous external clients and on occasion have found that >> depending on what product they use for FTP, their file transfer may in some >> fashion refer to our root directory or potentially the file transfer client >> being used defaults to a root directory. >> "In some fashion" may mean the conventional command, "cd /". The customary way to sequester this is to "chroot" after forking the child. >> In order to prevent such access were planning to change each userids >> OMVS segment to have a HOME directory of: /u/userid. (Currently we just use >> / .) >> -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: I need help about tuning NFS
On Tue, 20 Mar 2012 17:11:54 +0100, Marc Manuel wrote: > >I've just setup the nfs server on z/OS 1.11. > >From an AIX 6.3 client, I try to copy 395 mvs files, ... >cp /mnt/mvs/* /data/mvs > >IKJ56220I DATA SET UDMZ.A500.TESTNFS.AR82000.C1904293 NOT ALLOCATED, TOO >MANY DA >IKJ56220I MAXIMUM NUMBER OF DATA SET ALLOCATIONS ALLOWED BY YOUR SESSION >HAS BEEN REACHED, YOU SHOULD FREE UNUSED DATA SETS > >I don't understand IKJ56220I which is, as far as Iknow, a TSO message... > (TSO or DYNALLOC) This strikes me as a bug in "cp". The messages mean what they say, and "cp" (or perhaps NFS server) is not freeing allocations in a timely fashion. Open a PMR. IBM support is likely to tell you, "Increase DYNAMNBR." Stand your ground and escalate. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Theology question
On Tue, 20 Mar 2012 10:54:50 +0100, Thomas Berg wrote: >The only alternative (as seen from the principle of least astonishment) I can >think of is using the explicit option "NULL" - assuming that value is never a >"real" option. > In some contexts, such an option is unjustified. Designs should attempt not to restrict value spaces. >BTW, In rexx if you check for an existing parm would "rexxfunc(arg1,,arg3)" >have a *non-existing* arg/parm nr 2 but "rexxfunc(arg1,'',arg3)" would have >and *existing*, but "empty" arg/parm nr 2. > Empirically, yes: 5 *-* trace R 7 *-* Junk = rexxfunc(arg1,,arg3) 13 *-* rexxfunc: 14 *-* return( arg( 2, 'Exists' ) ) >>>"0" >>> "0" 8 *-* Junk = rexxfunc(arg1,'',arg3) 13 *-* rexxfunc: 14 *-* return( arg( 2, 'Exists' ) ) >>>"1" >>> "1" 9 *-* junk = arg( 1,) >>> "" 10 *-* junk = arg( 1, '' ) 10 +++ junk = arg( 1, '' ) IRX0040I Error running ./fooargs, line 10: Incorrect call to routine Since you ask the question, I checked the doc at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a3a0/4.3.4 I can see that it doesn't make this explicitly clear in the examples given. Is an RCF merited? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Theology question
On Mon, 19 Mar 2012 17:43:45 -0400, Gord Tomlin wrote: >IMHO using '*' to represent null violates the Principle of Least >Astonishment. '*' is often used in masking to represent "anything", >which is a long way from null. > >How about using NULL to represent null, e.g., > >thing3(option1,NULL) /* This would define another thing and say "even >if you have a default, global value for option2, pretend you don't" */ > I am very accustomed to, and comfortable with the convention common to Rexx and POSIX shell script, both of which distinguish between undefined and any defined value: empty string, "NULL", or whatever. So, I'd add the rule: thing3(option1,NULL)/* Means option2 is unset. */ thing3(option1,'NULL') /* means option2 is the 4-character string, "NULL".) ... (reserved words are never quoted; values are quoted to avoid conflict with reserved words or when lexically required, to avoid any encroachment on the potential value space.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Password Phrase Encryption Algo?
On Mon, 19 Mar 2012 16:19:37 +, Costin Enache wrote: >Of course. The final result looks like SHA-1, but several operations could >take place before - DES, etc. At the end it is a cryptographic operation. The >corect question would be - how are the passwords hashed, and potentially >encrypted, for RACF passworh phrases? > A one-way hash should be preferble to encryption because there should be no possibility that the key could be stolen. A dual-key ciphersystem with one key discarded is comparable to a one-way hash. From: Kirk Wolf Sent: Monday, March 19, 2012 4:17 PM Sorry if I'm being pedantic, but SHA-1 is not an encryption algorithm - it is a cryptographic hash function. http://en.wikipedia.org/wiki/Cryptographic_hash_function On Mon, Mar 19, 2012 at 9:09 AM, Costin Enache wrote: > > Does anybody have a clue how the > PASSPHRASE is encrypted in RACF? It looks very much like SHA (SHA-1 I > hope), it depends on both the username and password, but how is it > build? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEFBR14
On Sun, 18 Mar 2012 10:02:28 -0400, Gerhard Postpischil wrote: >On 3/18/2012 9:03 AM, Ron Hawkins wrote: >> And finally, my memory may be a bit dodgy nowadays, but it's my recollection >> that the EOF for empty datasets was introduced so that DFSMShsm and DFSMSdss >> could migrate, move and copy empty datasets. When there is no EOF for a zero >> empty dataset these utilities choke and spit it back. I don't think security >> was an objective. > IIRC, there was a time in prehistory or thereabouts when HSM choked attempting to migrate a properly formatted PDS with no members. There might have been a mismotivated performance concern here: If it's empty, it's more efficient to delete and later reallocate than to migrate and recall. >When you use the ALLDATA option, DSS copies whatever exists past >the last valid EOF. ... > Presumably also past DS1LSTAR? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Leap seconds and the Server Timer Protocol
On Tue, 13 Mar 2012 16:12:07 -0500, John Gilmore wrote: > >The sequence > > 2012 June 30, 23h 59m 59s > 2012 June 30, 23h 59m 60s > 2012 July 1, 0h 0m 0s > >will certainly appear in the transmitted sequence, but its middling >term was chosen to call attention to itself precisely because it is >NOT a valid date-time value. It appearance does not legitimate the >notion that 60 is a valid term in a zero-origin cycle modulo 60. The >mathematics of these things has been settled since Gauss. > Your second sentence is quite true. But what is your authority for asserting that the seconds (as they may have been respecified by UTC) must be a zero-origin cycle modulo 60? The excerpt above from IERS Bulletin C: http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat ... and the Wikipedia article cited by the author of WP102081: http://en.wikipedia.org/wiki/Leap_second ... both appear to imply otherwise. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Leap seconds and the Server Timer Protocol
On Tue, 13 Mar 2012 16:45:35 -0400, Robert A. Rosenberg wrote: >At 14:41 -0500 on 03/13/2012, John Gilmore wrote about Leap seconds >and the Server Timer Protocol: > >>This is the title of a new this month IBM Techdocs White Paper, >>WP101091, by Gregory Hutchison, a PDF of which can be downloaded from >>the IBM Techdocs website. > >What is the URL of the site? > GIYF. http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102081 (after correcting the WP#) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Leap seconds and the Server Timer Protocol
On Tue, 13 Mar 2012 14:41:32 -0500, John Gilmore wrote: > >Be aware that the next leap-second insertion will be at 11:59:59 UTF >on 30 June 2012. > UTF? I don't know the TLA. But I'd say UTC 23:59:59.999..., perhaps a second later than yours. And I know we disagree on this, but, from: http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat A positive leap second will be introduced at the end of June 2012. The sequence of dates of the UTC second markers will be: 2012 June 30, 23h 59m 59s 2012 June 30, 23h 59m 60s 2012 July 1, 0h 0m 0s (At least according to some authorities there is a 23:59:60.) There's a proposal, recurrently deferred, now until 2015, to eliminate leap seconds. I'd prefer to see UTC abolished. Let the physicists use TAI; let the astronomers and IT people use UT1, smoothed and announced a few weeks in advance. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
On Tue, 13 Mar 2012 07:54:06 -0500, McKown, John wrote: >Going back into the dark days of history, CICS has often done things which the >OS can also do. One thing I remember was it implemented its own version of >program fetch. It would read the directory entry for a program, allocate the >correct amount of storage in the CICS managed DSA (Dynamic Storage Area), then >do BSAM READs to bring in the program as well as perform address relocation. >Why? Because using a OS/360 LOAD macro would cause the entire region to "wait" >while the program was loaded. By doing the function itself, it could do >asynchronous reads and dispatch other transactions while the waiting for the >READ to complete. Remember, this was in the days of very slow SLEDs such as >3330 disk drives and slow machines. > Sigh. Conway's Law. YA case of IBM's implementing valuable function in the wrong layer, thus depriving other components of its use. The proper approach would have been to provide a NOWAIT option to LOAD, with an ECB to be POSTed when the operation completed. Or, simply, for CICS to ATTACH programs and go about its business. (But when does ATTACH return to its caller? Immediately, or after performing a LOAD?) What does CICS do nowadays about Program Objects: o Use the Program Management API to fetch them? o Use non-GUPIs to fetch them? o Hardware and software (particularly with deferred fetch) are so much faster nowadays that it doesn't matter? o Prohibit use of Program Objects and require Load Modules? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEFBR14
On Tue, 13 Mar 2012 15:38:35 +0100, Vernooij, CP - SPLXM wrote: > >~ The system took a longer time to run a job, job step, or procedure >than the time specified in one of the following: > >- The TIME parameter of the EXEC or JOB statement > >- The standard time limit specified in the job entry subsystem > Why should this peculiarly affect IEFBR14? (Although, to be fair, Gerhard never denied that it affected all programs.) > >Given enough dd statements, on a slow processor, it will take enough >time to exceed a small standard time limit. > Wouldn't a better solution than a specialized IEFUTL be to increase the standard time limit, at least enough to accommodate IEFBR14? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEFBR14
On Tue, 13 Mar 2012 10:26:33 -0400, Gerhard Postpischil wrote: > >there is one case that I have not seen mentioned - in the dark >ages, under release 21 of OS/360(MVT), IEFBR14 steps on our >system abended with S322. I had to write a special exception >into IEFUTL to allow allocation to complete. > I'm curious. You must have investigated. Is the ABEND o Because of something IEFBR14 did? o Because of something IEFBR14 didn't do? o Because of some unwarranted assumption made by "[your] system"? o Was there a divide-by-zero error involved? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
On Tue, 13 Mar 2012 11:46:39 +, Jousma, David wrote:
>I just read about that. Not sure it is too helpful, unless I am
>mis-understanding it? Time changes at 02:00 local time, based on what I
>read, the CICS clock would be off for the next 22 hours until the next local
>midnight?:
>
>AUTORESETTIME
>The AUTORESETTIME parameter specifies the action CICS should take if, at the
>next local midnight, the CICS time-of-day differs from the system time-of-day
>by more than 30 minutes; for example, setting clocks forward or back to adjust
>for summer and winter time.
>
>AUTORESETTIME={NO|YES}
>Valid values are as follows:
>NO
>CICS issues message DFHAP1500 to indicate that a CEMT PERFORM RESET command is
>required to synchronize the CICS time-of-day with the system time-of-day.
>YES
>CICS issues a PERFORM RESET command to synchronize the CICS time-of-day with
>the system time-of-day
>Note: Setting clocks back might cause end-of-day statistics to be written
>twice.
>
Sigh. Sounds like a powerful argument for performing the RESET
instantaneously instead of at midnight. Or the customer's using
auto ops to issue the RESET command every day at 01:01 and 02:01.
Why does CICS even have its own time-of-day when there's a perfectly
good system time-of-day it could use? Simpler is better. And why a
30 minute fuzz? One second should be enough to trigger a RESET.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEFBR14
On Mon, 12 Mar 2012 12:18:23 -0500, Mark Zelden wrote: > >>But why not write the EOF unconditionally, ... > >I don't know under what thread subject and when, but this has been >discussed on IBM-MAIN before. I'm not going to try and find it, >but you can. I'm sure there's a good reason. :-) > As has the OP's question been discussed in these fora, perhaps even more often. Perhaps the answer to him should have been "Search the archives." Now, perhaps wandering into new territory, IBM's z/VM CMS and IBM's z/OS UNIX System Services, both employing a simulated FBA DASD architecture, allocate a block only when it is written. An attempt to read a block that hasn't been allocated and written returns binary zeroes. (An attempt to read a block beyond the highest relative block written returns some sort of EOF indication.) This gives some faint hope that when the mythical FBA for z/OS comes to pass it could be implemented in a likewise orderly manner. I suppose the same could be achieved for CKD data sets by maintaining a bitmap of used tracks, which would add only .00025% overhead to the size of a data set. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
On Mon, 12 Mar 2012 16:58:44 -0600, Jerry Whitteridge wrote: >CICS needs a nudge to pick up the timechange - we issue a > >F CICSNAME,CEMT-PERFORM RESET > Why? Couldn't this be automated with a PARM? >To each region following the automatic change (We are on Sysplex Timers) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEFBR14
On Mon, 12 Mar 2012 10:40:27 -0500, Mark Zelden wrote: > >As John M. hinted, it does require a valid DSORG. > But why not write the EOF unconditionally, regardless of DSORG? The only reason I can imagine not to do so is if the programmer is alocating absolute track addresses to recover a deleted data set. (Of course, some DSORGs are automatically initialized (PO?), and for those, writing an EOF is superfluous.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tips for continuing DD statement with only one parameter field
On Fri, 9 Mar 2012 08:33:11 -0500, Shmuel Metz (Seymour J.) wrote: > >>Better: tilde substitution in the PATH. Where I work, user homes >>are not in /u. And some people mount HOME via NFS from a system >>with YA naming standard. > >Is there an outstanding requirement to support UNC in z/OS Unix? > How would that affect the syntax or semantics of the DD PATH= parameter? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
On Thu, 8 Mar 2012 14:01:03 -0600, Tom Marchant wrote: > >In order for this to work correctly, an ENTRY statement >is needed: > >//SYSLMOD DD DSN=main.loadlib >//NEWMOD DD DSN=load.library.where.you.put.the.new.module >//SYSLIN DD * > INCLUDE NEWMOD(BA4C1426) > INCLUDE SYSLMOD(BA4C1976) > ENTRY BA4C1976 > NAME BA4C1976(R) > Or not. I've never used it, but an alternative would seem to be: //SYSLMOD DD DSN=main.loadlib //NEWMOD DD DSN=load.library.where.you.put.the.new.module //SYSLIN DD * INCLUDE NEWMOD(BA4C1426) INCLUDE -ATTR SYSLMOD(BA4C1976) NAME BA4C1976(R) This kills many birds with one stone: AC, AMODE, DC, OL, REUS, RMODE, SSI, TEST, entry point, DYNAM, and MIGRATABLE. I suspect this option was introduced to support invocation of Binder by IEBCOPY. I expect a regular contributor to this forum to bristle at such a lazy shortcut. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tips for continuing DD statement with only one parameter field
On Thu, 8 Mar 2012 11:29:38 -0600, McKown, John wrote: >> -Original Message- >> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford >> Sent: Thursday, March 08, 2012 11:02 AM >> >> You saying the working directory on Z/os unix is different >> than the homes? >> I really, really hope that was intended as whimsy. > >Sure "current working directory" is not always the HOME subdirectory. It is >whatever directory was last referenced via the "cd" command or the C "chdir()" >function or via the callable services: BPX1CHD (24/31 bit) or BPX4CHD (64 bit). > Or with Rexx "address SYSCALL chdir ..." And this works even under TSO, and it stays changed after the EXEC or program exits. Yes, I'd like to see DYNALLOC respect CWD. But the problem remains: should the binding be performed at time of allocation, or at time of OPEN? Even now, one can DYNALLOC a path; delete the referenced file, then OPEN, which fails. IBM has taken a RCF on this WAD behavior. Better: tilde substitution in the PATH. Where I work, user homes are not in /u. And some people mount HOME via NFS from a system with YA naming standard. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tips for continuing DD statement with only one parameter field
On Thu, 8 Mar 2012 09:02:47 -0500, John Gilmore wrote: > >2) many historical keyword subparameters, e.g., those of the DCB= >keyword parameter, have been half promoted: they continue to be usable >as subparameters, but they may now also be coded as parameters > All DCB subparameters, or only some? And when used in connection with PATH=..., they may be used only as parameters, not as DCB subparameters. I suspect the need to enforce this restriction embodies the rationale for promotion of those subparameters. >5) The curious restriction that positional parameters must precede >keyword ones has been retained, a long, long time after its relaxation >in the HLASM macro language > But note that despite appearance PGM=... is not a keyword parameter but a positional parameter whose allowable values are required to contain "=". >6) In these and other respects JCL has become a patchwork. It is no >longer coherent: a knowledge of some of its facilities does not permit >plausible, almost invariably confirmed conjectures about the rest of >them to be made. > In this respect, it's highly consistent with the specification of HLASM. >7) Op. cit. [in the work (already) cited] is a suitable locution for >avoiding the repetitive full identification of a document. In >standard scholarly usage it must be accompanied by a page number, >paragraph reference, or the like; and this requirement is a >particularly urgent one when the document in question contains >multiple, not entirely consistent discussions of the same topic. > "not entirely consistent" could be material for an RCF. Would "loc. cit." have been better? (But I was merely too lazy to verify the reference.) The online IBM manuals are infuriating in this respect: They provide a link to the publication title, but not to the page nor the chapter title, and when I follow the link I am presented with a list of every edition of publications matching the title. I hate JCL! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tips for continuing DD statement with only one parameter field
On Thu, 8 Mar 2012 06:48:52 -0800, Charles Mills wrote: >PATH is not only under-specified in the JCL reference, it is also >over-specified. > >- Is case-sensitive. Thus, /u/joe and /u/JOE and /u/Joe define three >different files. > >Is not an aspect of the PATH= parameter, it is an aspect of the HFS. >Logically they could change HFS tomorrow to be non-case-sensitive (granted, >it ain't gonna happen -- I'm just talking logic here) without touching the >PATH= code and the above sentence would no longer be true. Or I could write >a product that mounted a remote Windows volume as an HFS volume and the >above sentence would not be true. /u/Joe and /u/Fred are also different >files, but that's an aspect of HFS, not of PATH=. > I very much agree. Add, as aspects of the HFS, not of JCL: o Multiple consecutive slashes are equivalent to a single slash, and even: o The slash serves as a directory level separator. o Any discussion that mentions the distinction between directories and filenames doesn't belong to JCL. The JCL RM should leave the specification of the UNIX filesystem(s) to another document, with citation (including page number), and mention only the limitations peculiar to JCL (and allocation) such as: o Pathnames must be absolute (start with "/") o 255 character limit o restriction on permissible characters o (Others?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tips for continuing DD statement with only one parameter field
On Wed, 7 Mar 2012 19:04:40 -0800, Charles Mills wrote: >Well, who's counting indeed, but my JCL reference says > >The pathname: ... >- Has a length of 1 through 255 characters. ... > I stand corrected; I misread earlier in the same section: Each directory or filename: Is preceded by a slash (/). The system treats any consecutive slashes as a single slash. ... Has a length of 1 through 254 characters, not including the slash. But now I've read it more carefully and submitted the RCF: Hello, MHVRCFS In: Title: z/OS V1R13.0 MVS JCL Reference Document Number: SA22-7597-15 12.48.2 Subparameter Definition pathname Is incomplete, perhaps misleading. The description appears to prohibit the following which are in fact allowed: o A pathname need not contain a filename; it may consist solely of directories, in which case it refers to a directory. o If (and only if) a pathname refers to a directory, it may end with a slash. The following may be implicit, or perhaps needs clarification: o The list of directories may be empty; the path may consist of only a filename, in which case it refers to a file in the root directory; or of only a slash, in which case it refers to the root directory itself. The following appear to be permitted, but are in fact invalid: o A slash may not appear in a directory or filename; it may be used only as a separator between directories and the filename. o The forms "." and ".." may not be used as filenames; these are reserved for directory names. If all this is explicit in other IBM publications, it would be better to shorten 12.48.2 and supply a cross-reference to such publications. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tips for continuing DD statement with only one parameter field
On Wed, 7 Mar 2012 18:54:47 -0500, Tony Harminc wrote: >On 7 March 2012 18:27, Charles Mills wrote: >> Many long threads here on that one ... >> >> What's worse, "parm" means two different things. >> >> There is a limit of 100 characters on the operand of PARM=. >> >> But I was referring to "parameters" in the more general sense of, as the >> manual says, "The parameter field consists of two types of parameters: >> positional parameters and keyword parameters. All positional parameters must >> precede all keyword parameters. Keyword parameters follow the positional >> parameters." > >Even worse, they probably should've been calling them arguments all >these years... > >> Some of those "parms" such as PATH= can have operands with a length of 255 >> characters. > >No, uh, argument. > No, uh, the passage Charles quoted appears verbatim in article "3.1.1 Parameter Field" of: Title: z/OS V1R13.0 MVS JCL Reference Document Number: SA22-7597-15 (or have you submitted an RCF that will appear in a future edition?) Op. cit. limits PATH to 254 characters, but who's counting? Anyway, that's closer to 255 than to 100. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: bkserv?
On Wed, 7 Mar 2012 19:44:24 -0600, Paul Gilmartin wrote: >Firefox is telling me about: > >http://www.ibm.com/systems/z/os/zos/bkserv/ > >The page isn't redirecting properly > >Firefox has detected that the server is redirecting the request for this >address in a way that will never complete. > >* This problem can sometimes be caused by disabling or refusing to accept > cookies. > >Grrr... I was in there within the last hour. What changed? > Transient; all better now. About in the time it would take a web developer to test (they do that?) recognize his mistake, and repair it. Sorry for the interruption; back to nostalgia. gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
bkserv?
Firefox is telling me about: http://www.ibm.com/systems/z/os/zos/bkserv/ The page isn't redirecting properly Firefox has detected that the server is redirecting the request for this address in a way that will never complete. * This problem can sometimes be caused by disabling or refusing to accept cookies. Grrr... I was in there within the last hour. What changed? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
On Wed, 7 Mar 2012 17:36:39 -0500, zMan wrote: > >Whatever you do, you want to use SSL or equivalent. FTP is dead in the water. > Have you discussed this with the developers of, e.g., the SMP/E RECEIVE FROMNETWORK command? I'm waiting breathlessly for the next release. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: TAPEMAP generator
On Tue, 6 Mar 2012 10:42:57 -0600, Elardus Engelbrecht wrote:
>af dc wrote:
>
>>I need to do a tapemap for about 100 tapes (virtual volumes), I've jcl:
>
>>what is the best way to generate 100 jcls ??? rexx ? icetool ?
>
>First loop is for each line containing volser and second loop is generating a
>full JCL for each volser.
>
> ...
>"ALLOC DA('') F(AFVOER) OLD REUSE"
>LYNE = 0
>
(Yes, but does the OP have the Rexx Afrikaans language feature installed?)
>JCL.0 =
>
I wouldn't bother with counting lines; I'd write each line to
the data set directly with a procedure such as:
PutAFVOER: procedure
parse arg LYNE.1/* Argument is one line of JCL. */
'EXECIO 1 DISKW AFVOER (stem LYNE.'
return
Performance? how many times will this be used?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: TAPEMAP generator
On Tue, 6 Mar 2012 16:03:05 +, af dc wrote: >Hello, >I need to do a tapemap for about 100 tapes (virtual volumes), I've jcl: > >//V1 EXEC PGM=IEBGENER >//SYSPRINT DD SYSOUT=* >//SYSOUT DD SYSOUT=* >//SYSUT1 DD DISP=OLD, >//DSN=AL2999.SOMETH, >//DCB=(RECFM=FB,LRECL=80,BLKSIZE=800,BUFNO=50), >//UNIT=(VTS),LABEL=(1,BLP,EXPDT=98000), >//VOL=SER=V1 > >and I've volume list in format: > >V1 >V10001 >V10002 >... > >what is the best way to generate 100 jcls ??? rexx ? icetool ? > The best way is a POSIX shell script, but Rexx would do. (I don't know ICETOOL or perl.) 100 jobs? Or one job with 100 steps? Would it be better to direct the output to various data sets with the tape volsers as qualifiers, or even to a PDS or UNIX directory with the tape volsers as member names? IEBGENER? Are you going to dump the entire tape data set content? "SYSOUT DD"?? Did you mean SYSUT2? CABAListically, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On Mon, 5 Mar 2012 14:17:07 -0700, Mark Post wrote: > >Most Linux operating systems read the hardware clock during the startup >process, and use that to set the system clock. NTP takes over from there, but >only affects the system clock, not the hardware clock. The system only tries >to set the hardware clock when shutting down. > But that "system clock" needs some sort of frequency reference. I wouldn't imagine that polling NTP provides fine enough granularity. What does it use? >There is only one source of time on Linux, and that's from the kernel via the >gettimeofday syscall. So, all processes go to the same place to get their >time information. > What a concept! You mean none of them do STCK(E) and variously apply corrections from the CVT, sometimes correctly; sometimes not? What if they're running in SRB or whatever mode, and can't issue SVC? (Never mind!) >There were some changes to the kernel a while ago that made it aware of >ETR/STP. I never looked at the code to see if it involved any attempts at >modifying the hardware clock. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On Mon, 5 Mar 2012 10:19:03 -0500, Steve Conway wrote: >Ed Jaffe said: >IMHO, STP should be included in the price of the machine. > >I totally agree. There should also be an option to use NTP. Not every >shop needs the granularity of STP, and they damn sure don't want to pay >for functionality that comes free on every other piece of hardware in the >house.. > >Right now, the choices are either to pay $BIGNUM for time keeping software >unique to the hardware platform or to have no time keeping software. > >When I'm trying to advocate a zBox as cost effective, this does not help. > Would your argument from TCO be any more effective if IBM bundled the STP and raised the base system price by the now cost of the STP? (It's possible; the number of line items has negative weight regardless of the bottom line.) But what's the business case for IBM? Would increased revenue per sale offset loss of sales in the non-STP niche market? And if an ISV provided clock steering software based on NTP, would this, Neon-like, violate any IBM legal constraints? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On Mon, 5 Mar 2012 14:19:33 +, Pate, Gene wrote: >I am amazed at the uproar over this. Is there anything that a PCFLIH backdoor >can accomplish that any AC=1 module in any APF authorized library cannot? >Is there anyone else out there that is running any vendor code for which they >have not done code reviews that is running AC=1 in any APF authorized library? >Is there anyone else out there that is running any home grown code with an >AC=1 in an APF authorized library for which they have not done code reviews? >Is there anyone else out there that has libraries in the APF list that can be >updated by anything other than there change control system that only allows >modules that have been through code reviews to be installed in their APF >authorized libraries? > >How you allow code to get into supervisor state is of no consequence once it >is in supervisor state so, unless you have a pristine system where every load >module library on the system is totally locked down ... > Not "every". I believe IBM's SOI applies regardless of what mey be put in non-authorized load libraries. >and only the OS libraries supplied by IBM appear in the APF list, you have by >definition accepted exposures to system integrity. Does your management >understand just how exposed you have left all the company secrets? > Or, by your earlier paragraph, suitable review is performed for non-IBM code. And even then, IBM's SOI doesn't apply. But why do you trust IBM? Their code is OCO and difficult to review. I suppose it's possible if one signs the required NDAs and pays the charges. Is there any independent commercial body that so reviews and certifies IBM's code? And even indemnifies? For a price, of course. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On Sat, 3 Mar 2012 10:39:32 +0100, R.S. wrote: >W dniu 2012-03-03 07:34, Edward Jaffe pisze: >> >> IMHO, STP should be included in the price of the machine. > >Or at least "STP light" which would allow to use ETS (NTP). >However it's NOT incluted. :-( > I like that idea. Is the hardware associated with STP physically disabled until the customer pays for the feature? If not, is the hardware sufficiently described in the PoOp (PrOp) that such an interface to NTP could be developed by an ISV, or even privately and contributed to cbttape? (No, I'm not volunteering.) What does Linux for z use for clock steering? I understand it was never ETR-savvy (nor was z/VM?) I imagine it might be done by letting the ETOD clock run free and allowing NTP to update parameters of a software offset used by all system time services (kinda like CVTLSO). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On Fri, 2 Mar 2012 19:31:55 -0600, Joel C. Ewing wrote: >On 03/02/2012 06:44 PM, Charles Mills wrote: >> And the answer from those who know is >> >> "It happened during the POR last Thursday and we're talking with IBM to >> figure out why a POR would do that to us." >> >> Thanks all for your patience with YATQ (yet another time question). >> >> Charles >> > >In absence of sysplex timer or the like, the processor TOD clock is set >only at POR and is set based on the HMC clock, which may in turn sync >once a day with the SE clock. If you don't have any procedure to sync >the HMC/SE clocks to UTC or verify they are reasonably accurate when you >know a POR is imminent, odds are they have drifted from reality and a >POR will propagate that error to the processor TOD clock, which in turn >propagates to all LPAR TOD clocks as they are activated. It would seem >your operators must be setting local time explicitly at IPL (rather than >using a fixed offset from TOD), or the error would have been more >obvious after the IPL.My recollection is it has worked this way ever >since IBM mainframes have had HMCs for control. > And the fun part is, I think it takes another POR to get things all synched up. Does anyone else see anything wrong with this picture? -- gii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Calling Authorized Assembler from REXX
On Thu, 1 Mar 2012 15:45:43 -0600, Betsy Jeffery wrote: > >* The program issues MVS command to modify a CICS region (f, region-name cemt >blah, blah) via SVC 34. >* The REXX itself is not allowed (by the Info Security folks) to issue the >commands. > ??? But it can call a program in some other language that does the same thing??? >The REXX Call is: >arg1 = 'PS0903A' > >ADDRESS tso > Call CICSCMDT ARG1 > Shouldn't that be: address TSO "call CICSCMDT '"ARG1"' " -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert "historic" STCK to local time?
On Thu, 1 Mar 2012 16:08:46 -0500, Tony Harminc wrote: >On 1 March 2012 16:01, McKown, John wrote: > >> What would I like? A complete GNU tool chain. Also, current versions of >> Perl, python, ruby, gawk, sed, grep, bash, vim, emacs(?). Of course, I >> realise that IBM cannot afford to supply these things for free. I, >> personally, cannot attempt to "port" this because: (1) we don't have a C >> license; (2) we are CPU critical and constantly monitoring to reduce our >> MSUs to reduce our software costs; (3) I likely don't have the talent. > >You're not likely to see a z/OS python, I think. Python's creator is >EBCDIC-hostile, and even rejected some carefully thought out support >code that someone else contributed a few years ago. > This is an example of why I'd like to see a fully ASCII-friendly Unix System Services. You should just be able to compile Python and it should Just Work. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert "historic" STCK to local time?
On Thu, 1 Mar 2012 05:47:38 -0600, Jan MOEYERSONS wrote: > >>Sanely organized networks, even those that do not span multiple time >>zones, collect and store only UTC [GMT] STCKE values. >> >>The table involved is short; it is ordered; it can be searched using >>very efficient glb-seeking binary search; this table grows very >>slowly; elements can be added to it before their effective dates; >>ample advance notice of requirements to add new elements and their >>effective dates (always one of two) is provided; etc., etc. > >All true. And all too bad IBM did not implement such table into their C >library functions. > Sounds like material for a Requirement. And ICANN provides the necessary data; I've posted the link a couple times in this thread. But is there a business justification? Alas, "Most of the rest of the world does it that way" is unlikely to suffice. To IBM's credit, the one time I reported a leap second error in an IBM product, they swiftly provided a PTF, properly, IMO, switching to use the TIME macro instead of STCK and ad-hoc conversion. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert "historic" STCK to local time?
On Wed, 29 Feb 2012 15:43:02 -0500, John Gilmore wrote: >Paul Gilmartin writes: > > >STCKE is notionally closer to TAI than to UTC in that TAI and STCKE >are continuous timescales and UTC is discontinous. TAI and STCKE both >embody the notion of (micro)seconds since an epoch; UTC is specified >in terms of mm dd hh mm ss.fraction with minutes varying in >length as leap seconds occur. > > >Note quite. This formulation is plausible by analogy with the notion >that the Gregorian Month of February, normally comprised of 28 days, >is comprised of 29 days in leap years. > >Leap seconds, however, are inserted into UTC by the BIPM upon the >recommendation of the IERS (Earth Rotation and Reference Systems >Service); and they are conceptually and by definition >extracalendrical. Neither 1) the last minute in June or the first >minute in July nor 2) the last minute in December or the first minute >in the subsequent January is lengthened when a leap second is inserted >between them. [This decision was taken advisedly. There are a number >of calendars---The Hebrew religious one is the obvious example---that >make no use of minutes and/or seconds.] > And here, I'll disagree with you. The embolismic second is 23:59:60 of the previous day. I've seen it flash by with a telnet connection to NIST. (Or maybe they just had to call it something.) This seems to me no more extracalary than February 29. But it's all highly academic. By the way, the embolismic day in bissextile years is February 24, the sixth day before the kalends of March. (Spellcheck hates us.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert "historic" STCK to local time?
On Wed, 29 Feb 2012 11:07:31 -0600, Barry Merrill wrote: >FALSE: >Sanely organized networks, even those that do not span multiple time >zones, collect and store only UTC [GMT] STCKE values. > STCKE is notionally closer to TAI than to UTC in that TAI and STCKE are continuous timescales and UTC is discontinous. TAI and STCKE both embody the notion of (micro)seconds since an epoch; UTC is specified in terms of mm dd hh mm ss.fraction with minutes varying in length as leap seconds occur. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert "historic" STCK to local time?
On Wed, 29 Feb 2012 10:11:06 -0600, Bill Godfrey wrote: >On Wed, 29 Feb 2012 09:47:03 -0600, Paul Gilmartin wrote: > >>On Wed, 29 Feb 2012 09:12:20 -0600, Bill Godfrey wrote: >>> >>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB5A0/E.6.2 >>> >>>The value in the word returned by this routine is in seconds-since-1/1/1970, >>>but, unlike the value returned by the C library time() function and expected >>>by localtime(), it includes leap seconds, so for current dates it is 24 >>>seconds too high. >>> >>No, it's correct; POSIX is the one that's wrong here. (Those >>who suspect me of being invariably biased toward UNIX, >>please note.) >> > >Maybe some day I'll write a little test program that takes the STCK value for >1999 from the Principles of Operation table, run it through the logic, see >what gmtime() returns. I'm pretty confident it will be 22 seconds past >midnight because of the leap seconds. Maybe somebody else will do that before >I do, and prove me right or wrong. > I'm confident that you'll be right. I consider POSIX wrong here. And I'm likewise confident that POSIX will provide the rationale that so often dismays me here: too much legacy code depends on the incorrect behavior ever to change. >>>The value is also used in the Rexx code at these links: >>> >>> ftp://ftp.boulder.ibm.com/s390/zos/tools/wjsip/wjsigamu.txt >>> >>> ftp://public.dhe.ibm.com/s390/zos/tools/wjsigshl/wjsigshl.txt >> Wikipedia, which is always right, says of an active proposal to abolish leap seconds: http://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish_leap_seconds o October 2011: The ITU-R released its status paper, Status of Coordinated Universal Time (UTC) study in ITU-R, in preparation for the January 2012 meeting in Geneva; the paper reported that, to date, in response to the UN agency's 2010 & 2011 web based surveys requesting input on the topic, it had received 16 responses from the 192 Member States with "13 being in favor of change, 3 being contrary."[21] o January 2012: The ITU decided to postpone a decision on leap seconds to the World Radio Conference in 2015. France, Italy, Japan, Mexico and the US were reported to be in favor while Canada, China, Germany and the UK were reportedly against.[22] Others including Nigeria, Russia and Turkey called for more study. The BBC states the ITU decided further study of broader social implications was needed.[23] And, repeating: http://www.iana.org/time-zones http://en.wikipedia.org/wiki/Tz_database -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert "historic" STCK to local time?
On Wed, 29 Feb 2012 05:53:14 -0600, Jan MOEYERSONS wrote: >On Tue, 28 Feb 2012 19:45:11 +, Rob Scott wrote: > >>Obviously this assumes you know the UTC offset at the time of the LPAR >> >And that is exactly where it hurts... How does one know what the offset was at >the time the timestamp was taken? Due to daylight saving, it is far from >obvious to determine the offset at any given moment in the past. > But the work has been done: http://www.iana.org/time-zones On Wed, 29 Feb 2012 07:05:04 -0600, Shane Ginnane wrote: > >Yep, it's called TZDATA. Pity IBM hasn't gotten sufficiently organized to >embrace it for z/OS >Damn, I guess that places me alongside gil/John. Thus a (nominal) triumvirate >- perchance to progress to a fully populated cabal someday ? > In fact, on this topic, both Johns. We lack only one of a quorum. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert "historic" STCK to local time?
On Wed, 29 Feb 2012 09:12:20 -0600, Bill Godfrey wrote: > >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB5A0/E.6.2 > >The value in the word returned by this routine is in seconds-since-1/1/1970, >but, unlike the value returned by the C library time() function and expected >by localtime(), it includes leap seconds, so for current dates it is 24 >seconds too high. > No, it's correct; POSIX is the one that's wrong here. (Those who suspect me of being invariably biased toward UNIX, please note.) >The value is also used in the Rexx code at these links: > >ftp://ftp.boulder.ibm.com/s390/zos/tools/wjsip/wjsigamu.txt > >ftp://public.dhe.ibm.com/s390/zos/tools/wjsigshl/wjsigshl.txt -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: User datasets wrongly catalogued under Master Catalogue
On Wed, 29 Feb 2012 09:14:36 +0530, Jake anderson wrote: > > typo - it happens when a userid is *not* defined with alias relating to >user catalog. > To my understanding, that's half right. It happens when a userid is *not* defined with alias relating to user catalog _and_ the master catalog is *not* suitably protected. I have a question on terminology: someone stated here lately that user catalogs are ancient history; no longer used. Is this so? If so, how are user data sets catalogued? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Originality (was: Duplicating SYSOUT ...)
On Tue, 28 Feb 2012 17:20:50 -0500, Shmuel Metz (Seymour J.) wrote: > >If you're licensed for z/OS then you're licensed for the members of >SAMPLIB. > Including creating derivative works? Where can I find this in writing? May I distribute such derivative works at least to other z/OS licensees? I suppose it's my responsibility to verify the license. I wonder how much code on cbttape.org is derivative of SAMPLIB or of examples in reference manuals? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On Tue, 28 Feb 2012 14:51:31 -0800, Edward Jaffe wrote: >On 2/28/2012 8:51 AM, McKown, John wrote: >> IOW, damned if I do and damned if I don't (insert hard line breaks, that is). > >My advice is not to ever insert any hard breaks. That just makes things worse. >When one relies on software that properly handles format=flowed everything >should work beautifully. Thunderbird seems to support this very well. I assume >Outlook does as well. > I'll take the contrary position. This ain't a word processor. I learned long ago to insert line breaks where I want them -- it's the big key to the right of the home row. Using this and presuming a monospaced font (terminals used to be that way; 3270s still are) I can enter tabular information using the space bar (the long key near my belly button), and even compose rudimentary graphics. for anything fancier, people should use a markup language (but which one? HTML? RTF? Other (specify)?) F=F is an abominable compromise. Q-P is no better. Both are attempts at stealth markup -- structured text that appears plain The games they play are never quite transparent. They corrupt plain text that I paste in. MS Exchange used to take JCL snippets that supplied and interpret such as "BLKSIZE=6144" as Q-P entities. (It was breaking the rules; Q-P was not declared in the MIME headers, but MS was governed by a principle of fewest phone calls, and more people would complain about seeing "=3D" in their emails because the sender omitted them, or they had configured LISTSERV to strip MIME headers, than about seeing "BLKSIZE=6144" become "BLKSIZEa44") When I paste in a snippet of a Rexx trace which flags its lines with ">>" on the left, my MUA, or perhaps yours, tries to interpret them as quotation flags. And F=F's attempt to reposition ">" to fit the screen width makes things even worse. I believe F=F uses as a continuation indicator. Woe betide anyone who allows a space to occur before a hard line break. Perhaps this is the source of R.S.'s problem. Leave my text alone, dammit! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert "historic" STCK to local time?
On Tue, 28 Feb 2012 20:11:09 +, Rob Scott wrote: >If you are lucky enough to be in control of the data collection, then you >could save the CVTLDTO value in the same control block or record as the STCK >value so that you can accurately re-construct local time at a later date. > And the data may be processed in a time zone different from the one in which its collected. Or, looking at it another way, the data center may be remote from the corporate main and branch offices. ... Why is this so hard a concept for the legacy mindset!? z/OS UNIX does far better than legacy z/OS, but it's still mediocre compared to Linux, OS X, and Solaris. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert "historic" STCK to local time?
On Tue, 28 Feb 2012 09:57:44 -0800, Charles Mills wrote: >Is there any straightforward way to convert an STCK value from some point in >the fairly recent (months, not decades) past to local time for the LPAR's >locale? By "straightforward" I mean without having to maintain my own table >of time changes for the historic period? > Subtract TOD value for Jan. 1, 1970. Divide by 4,096,000,000. Set time zone with tzset(). Call localtime() then strftime(). This is good back to about 2006 in the U.S.A. Linux does much better. Leap Seconds? You're SOL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
