Re: IBM-MAIN Digest - 18 Jan 2009 to 19 Jan 2009 (#2009-19)
Someone wrote: > USING FRED,15 >FRED CSECT > B SAVE-*(15) What value is in register 1 here? > L 15,0(1) What is in register 15 here? Remember, R15 is still the only base register, and will be used in the next instruction... > B RETURN > >SAVE DS 0H > STM 14,12,12(13) > BALR 11,0 > LA 0,*-FRED > SLR 11,0 > LA 2,SAVEAREA > ST 2,8(13) > ST 13,4(2) >* LR 13,2 > B4(15) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Ancient IBM Drive Rescues Apollo Moon Data
Rick Fochtman <[EMAIL PROTECTED]> wrote: > Will any of the more modern drives handle the appropriate density? > I'm not sure: will a 7-track 3420 handle 200 BPI? or 556 BPI? http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3420.html It seems that they do 556 and 800 normally, 200 requires a 2803-2. It even looks like they did 1600, though I don't ever remember anyone doing that. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: zArchitecture reference summary - the denounement
Steve Comstock wrote: Well, the prices did go down for these documents. It seems that the Principles of Operation manuals are still much more expensive than before. They used to be somewhat more reasonably priced than many of the software manuals. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Reference Summary
Steve Comstock wrote: Did you know the quoted price for these little gems (that came from the original S/360 "green card") are now priced at $173.82?!! It seems that z/Architecture Reference Summary (SA22-7871-04) is now down to $25.04. I think that is still high, but less than $173.82. I know they're downloadable for free, but I wanted to hand them out to a class in the little booklet form, not on 8.5 * 11 copy paper. But $173.82 for 84 pages? Plus shipping. The prices always include ground shipping, but not sales tax. What's up with that? Note: this is for the -04 version. The -03 version is only $52.64. Now only $8.63. but $65.88 for the -02, $6.11 for -01, $4.68 for -00. S/370 REFERENCE SUMMARY (GX20-1850-07) for $7.56. The Principles of Operation are still expensive, too. z/Architecture Principles of Operation (SA22-7832-06) $239.14, z/Architecture Principles of Operation (SA22-7832-05) $139.02, z/Architecture Principles of Operation (SA22-7832-04) $148.52, z/Architecture Principles of Operation (SA22-7832-03) $144.88, S/370 PRINCIPLES OF OPERATION (GA22-7000-10) $82.12, SYSTEM/370 EXTENDED ARCHITECTURE/INTERPRETIVE EXECUTION (SA22-7095-01) $13.30. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Reference Summary
Steve Comstock wrote: Did you know the quoted price for these little gems (that came from the original S/360 "green card") are now priced at $173.82?!! It seems that older ones have gone up, also. The S/370 reference summary, GX20-1850-07, used to be reasonably priced but is now $72.02. The -02 for z/Architecture, SA22-7871-02, is now $94.10. The -01 is only (only?) $35.96. The -00 is $24.87, almost affordable. S/370 Principles of operation is now $215.98! The z/Architecture Principles of Operation, SA22-7832-06, is now $1434.96! In the past, most of these were reasonably priced. Once one came out a little high, someone complained, and later ones came out lower, though the old ones didn't change. I hope someone can correct those prices. Maybe they are in Yen. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PC printing of .txt files containing maiframe listings
(someone wrote) I've got a freeware PC program that allows you to print output with mainframe control characters if that's what you want, send me an offline email and I'll send it to you. It is a standard part of the printing subsystem on many unix systems. It is called the "fortran filter", traditionally used for printing the output of Fortran programs. In the case of most unix systems, it converts to Postscript. If one doesn't have a PS printer the output is run through Ghostscript to convert to the appropriate printer output format. It seems to be built into the PPR printing system: http://ppr.trincoll.edu/ppr-doc-1.51/pprdoc/pprdoc.html -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Remote tape drive
(someone wrote) > Well, we create tapes that will be sent to a replication service > for sending software and data to customers. The media must be > 3490 and 3590. I can put 3490 drives on a Win32 or Linux box > easily enough (we have two 3490 SCSI based tape drives.) > But as I said, I don't know how to replicate an IEBCOPY > image. It might be that with the appropriate DCB, IEBCOPY will write an unloaded data set to disk. Otherwise, write a local tape with IEBCOPY, then copy to disk with IEBGENER. Then you have the unloaded data set on disk to transfer. You could also convert the tape to AWSTAPE or other emulated tape format and transfer that file to a remote site. It can then be converted back to a real tape again. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Remote tape drive
>I would like to have a tape drive at a remote office from where the > mainframe is physically located. Preferably a (normally) channel > attached tape drive, rather than a SCSI type of thing, although I > would take the latter if given no other choices. I have done it on unix using rsh (or ssh), something like. tar cbf 60 - . | ssh remotehost dd obs=30k of=/dev/tape That doesn't quite satisfy channel attached (to the source host). All that it requires is a TCP connection to get the data from one host to the other. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM-MAIN Digest - 26 Apr 2008 to 27 Apr 2008 (#2008-118)
Someone wrote: If I recall correctly, FORTRAN/PLI needed explicit exponentiation, i.e., DOUBLE A,B . A = B+1.23 would use a short 1.23 rather than determining that the other operands were double thus 1.23 should be treated as a double as well. One had to do A = B+1.23D0 Fortran traditionally used the exponent letter. PL/I traditionally used the form as written to determine the precision and scale. That is, 123.000E0 would be FLOAT DECIMAL(10). Binary used the suffix B, and the value was given in binary digits (with a decimal exponent). .011E3B for FLOAT BINARY(7). Some compilers now might support exponent letters other than E. Also, there are PL/I intrinsic functions if one wants a different base, scale, precision, or mode. BINARY(123E0,50) for example. C uses the suffix f for float (single precision), the default being double. More recently, Fortran has KIND specified with a suffix with the appropriate constant value, usually the result of an intrinsic function. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Trial execution for TR and TRT
Someone wrote: >>Assuming DAT on, is the performance hit related to the possibility >> that the following 4096 page is not in virtual memory? Lynn Wheeler wrote: > way back on 360/67 ... (actually all 360s) TR used to test start & > start+255 (end) address of the table ... which met that if it > crossed a 4k page ... it would catch both ... aka page fault both > pages ... before starting instruction execution. For S/360 models with DAT. > somewhere along the way ... something was raised that TR only > uses that much of the table that the input data-stream might > used ... for instance, if the translation input stream only > had values 0-9 ... and the table was within 256 bytes of the > end of an addressable region ... then the instruction might > fail (with start+256 precheck) ... even tho it otherwise could > succesfully execute. so the TR instruction was > "fixed" ... if the table start is within 256 bytes of the end > of an addressable boundary... it "pre-executes" the instruction > to see if any input stream bytes would index the table > across the boundary. S/360 GA22-6821-8 in the paragraph about logical operations at the beginning of the chapter and describing TR says: "In cases where it is known that not all eight-bit argument values will occur, it may be possible to shorten the list." > this would also theoritically have been a problem with 2k key fetch > protect ... and the table was within 256 bytes of a 2k boundary (with > the next 2k, fetch protected) and the input data stream never indexed > anything (in the table) across the addressable boundary. It seems like it would also be a problem on non-DAT machines at 4K boundaries. It does seem to have been added fairly late in S/370, though. (At least when it got documented.) I first learned about this in Nick Tredennick's book "Microprocessor Logic Design" about the Micro/370. http://en.wikipedia.org/wiki/Nick_Tredennick -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Convert EBCDIC to ASCII in batch?
> Actually, I think that I've found the problem. There appears to be a > firewall between the mainframe and the Windows box. The ftp which is > failing is large (small ftps succeed!) and my estimate is that it is > taking just a bit over 2 minutes to complete the data transfer. I > think the firewall is timing out the ftp control connection due to > "inactivity". I have so informed management. Maybe somebody there can > light a fire under the firewall people to get off their fundament and > actually look at it. It seems that many firewalls and NAT routers have much too short a timeout for such connections. Even ones that do TCP keepalive are often disconnected. I would say two minutes is way way way too short, though. Maybe 15 minutes is ordinary too short. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LZW Compression/Expansion
Rick Fochtman wrote: > I'm planning to unbutton ARCHIVER (CBT File 147) and will > be considering the replacement of the current Huffman tree > compression with LZW, if I can code it to be more efficient > in Assembler. I've been told by several users that while the > compression seems fairly quick, the "uncompression" seems to > be rather CPU intensive. Before anyone goes looking, please > remember that I wrote that code years ago, under MVS SP1.3. > I've also found that some load module records grow, rather > than shrink, when I apply the Huffman compression technique > to them, resulting in ABENDs. Between the unix (GNU) source to compress.c and the original LZW paper, it isn't too hard to figure out. I wrote one once using those. There might also be an explanation in the PDF documentation, as it is one of the compression methods used for PDF files. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Copying Unix tar file to tape
> I am trying to write out a Unix System Services file -- > a tar archive -- to tape. For simplicity's sake, I was > planning on using IEBGENER, but I'm a bit confused as to > what file characteristics to use for this. > Anybody out there have any sample JCL? Unix tar files have a length that is a multiple of 512. I would expect either RECFM=FB LRECL=512, or RECFM=U and a block size some multiple of 512. Each file stored in a tar file has a 512 byte header, and is padded to the next 512 byte boundary. If you change the blocksize, the data should be fine but you sometimes get a warning when tar gets to the end of the file. The blocksize is specified on the tar command with the b option as a multiplier of 512. That is, the default of 20 gives a 10240 byte BLKSIZE. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to find "current tape length" programatically
Someone wrote: > I have an obvious question on the 3490E though. > You say there is a set of tracks "going AND coming". > Since actual tape length isn't a specification, > just a minimum is, how would a hardware duplication > device handle a 3490E? > In theory it wouldn't be able to, would it? If one wanted to build a hardware device that could copy a tape, it would probably be possible to write all the tracks at once. As an example, analog cassette tapes can be duplicated in one pass writing both directions at the same time. I don't know the specific encoding for the 3490E, but most likely it is possible. Otherwise, one might copy one side from the beginning as far as it went, skip to the physical EOT, then start writing the other side from the end. Even easier might be for the tape duplicator to find tape stock sufficiently longer than others to guarantee that it will fit. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CRBE, CRJE, and WYLBUR
Someone wrote: > Back in the sixties American Management Systems sued IBM for > giving away free software, mainly CRBE, thus undercutting sales > of ROSCOE. AMS got a Pyrrhic victory, as IBM used this as an > excuse to start charging for software that otherwise would have > been free. Did they also sue NIH for distributing WYLBUR? I recently read a SLAC note about converting from CRBE to WYLBUR because IBM wasn't producing CRJE fast enough. I never did know the difference between CRBE and CRJE. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Printing a PDF or PS doc
Re: Printing a PDF or PS doc (someone wrote) (snip) > Nowadays I would expect that most large shops can deliver the data > directly from the mainframe over an LPR/LPD conversation to a UNIX or > Windows print server or can somehow drive a direct attached IP > printer. The secret in this case is to make sure the original ASCII > document is not translated to ASCII again and thus destroying its > content. Locally we reserve JES SYSOUT class T to mean "transparent" > assuring that any "binary" document (graphic image of any flavor or > any other file for that matter including PDF) is not retranslated. In addition, note that the conversion from PDF to PS is fairly simple. It should be possible to do that on the mainframe and then send the ASCII (or binary) PS file to an IP connected PostScript printer. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
TROT
(someone wrote) > Looking at the TROT example, which caught my eye not having > used the instruction before, I think there is a bug as TROT > can be interrupted according to POPS. > I posted a reply, but being an ejit at times, I may have > done something wrong as I cannot see it (yet?). > TROT R6,R8,1 TRANSLATE TO PRINTABLE HEX > I believe that it should be: > TROTTROT R6,R8,1TRANSLATE TO PRINTABLE HEX > BC1,TROT It looks that way to me, too. As far as I can tell, that is true even if one is sure that the length is not so long. That is, there is no minimum 'processor determined size' and, because of the retry function, it might even return CC3 and change the data later. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Reel tapes
Edward Jaffe wrote: > I found a box with several round tapes that must be converted > to CART (or better yet AWSTAPE format) but no longer have > access to hardware that can read them. People in the Hercules group can do it. If there is data (programs) of historical interest that could be released, I am sure it would be done free. Otherwise, it may or may not be free. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
